Podcast appearances and mentions of ben orenstein

Adam and Ben are back on the mics after nine months to give an update on their lives.Timestamps(00:00) - Catching up (00:18) - Fitness update (18:13) - House updates (24:53) - Ben update (35:11) - Tailwind Labs update LinksAdam on XBen on X

Ben and Adam Wathan cover the development and reimagining of Tailwind CSS, focusing on the release of Tailwind 4.0. They delve into the motivation behind the rewrite, the challenges faced, and the approach to maintaining backward compatibility. The conversation covers topics related to software versioning, open-source maintenance, backward compatibility, the use of Rust in Tailwind, testing strategies, and the future of Tailwind as a business.LinksTuple.app (https://tuple.app) - The best app for pair programmingTailwind CSS (https://tailwindcss.com) - The CSS framework Adam createdKey TakeawaysRewrites can lead to a cleaner, more maintainable codebase.Accurate problem modeling can lead to the emergence of new features and benefits.The approach to backward compatibility involves making it easy to upgrade to the new version rather than simply making the old version work.Chapters(00:00) - Introduction and Background (00:35) - Windows Version Launch and Guest Network (01:24) - Rewriting Tailwind: Philosophy and Execution (03:42) - Ben's Static HTML Website Idea (09:06) - Re-imagining Tailwind with Tailwind 4 (20:49) - Challenges and Solutions in Tailwind Development (32:45) - Rust Components in Tailwind 4 (35:41) - Tailwind 4 Goals and Achievements (40:22) - Testing and Quality Assurance in Tailwind 4 (46:38) - Tailwind 4 Release (49:54) - The Tailwind Origin Story (52:24) - Business Strategies and Open Source Impact

Ben and Matt discuss the role of a product engineer and Matt's journey as a content creator. Matt shares his experience working at a consulting agency and how it shaped his perspective on engineering. They also discuss the benefits of working in-person and the importance of the quality of coworkers. Matt reflects on his motivation for content creation and how it ties into his competitive nature. They touch on the changing landscape of content creation and the value of posting code snippets, and about Matt's experience getting hired at Arrows through Twitter and the value of demonstrating competence through content creation. They touch on the longevity of Ben's Ruby talk and the elements that make it stand out.LinksTuple.app (https://tuple.app) - The best app for pair programmingArrows.to (https://arrows.to) - An app for collaborative customer onboarding that Matt works onBoring Rails (https://boringrails.com) - Where Matt shares boring tools and practices to keep you as happy and productiveYAGNI (https://yagni.fm) - The podcast where Matt and look at software practices and tools and ask: "do we need it?"Key TakeawaysA product engineer is someone who writes code, cares about design and user experience, and is responsible for the end-to-end delivery of a feature.Working at a consulting agency can provide valuable experience by exposing developers to a variety of projects and domains.Content creation can be a way to contribute back to the community and establish oneself as an expert.Demonstrating competence through content creation can help in the hiring process.Long-lasting talks focus on practical ideas and good object-oriented design principles.Chapters(00:00) - Introduction and Matt's Role as a Product Engineer (07:11) - The Benefits of Working at a Consulting Agency (09:34) - The Importance of Quality Coworkers (13:41) - The Motivation for Content Creation (18:54) - The Value of Posting Code Snippets (24:03) - Packaging Content as an Event (26:40) - Demonstrating Competence through Content Creation (32:05) - Long-Lasting Talks: Practical Ideas and Object-Oriented Design (38:39) - 'Nathan for You': Creative and Mischievous Problem-Solving (41:30) - Unconventional Advertising: Selling Ads on the Penny (44:29) - Thinking Outside the Box: Unconventional Solutions

In this conversation, Ben and Derrick discuss the challenges of growing a business and the decision to target specific market segments. They explore the trade-offs between serving a broad audience and focusing on a niche market. They also discuss the technical choices and architectural decisions in building a product, with Derrick sharing his positive experience with Elixir and the Phoenix framework.LinksTuple.app (https://tuple.app) - The best app for pair programmingSavvyCal.com (https://savvycal.com) - The scheduling tool Derrick createdPhoenix (https://www.phoenixframework.org) - the Elixir framework SavvyCal is built onRails (https://rubyonrails.org) - the Ruby framework Ben worked withKey TakeawaysElixir and the Phoenix framework offer a maintainable and explicit approach to building applications.Functional programming paradigms can simplify code organization and improve maintainability. Object-oriented programming and functional programming have different approaches to code organization and maintainability.The active record pattern in Rails can lead to large and complex models, while the repository pattern in Phoenix provides a more modular and explicit approach.Open source contributions can be seen as a good faith contribution to the commons and can provide benefits such as status and marketing opportunities.Developers can improve their design skills by studying resources like the book 'Refactoring UI' and being introspective about user interfaces in their daily lives.Chapters(00:00) - Introduction and Background (02:12) - Savvy Cal and Horizontal Products (05:56) - Choosing Between Niche and Broad Audience (15:59) - Phoenix vs. Rails (22:20) - Object Oriented vs. Functional Programming (36:02) - The Motivations Behind Open Source Contributions (43:20) - Improving Design Skills as a Technical Person

In this episode, Ben chats with Thorsten Ball. This conversation fits neatly into two halves - in the first, Ben and Thorsten go deep on how to differentiate yourself, work in public, and make it easy for people to hire you. In the second part of the conversation, they talk more specifically about Zed, why it matters, and how it's being built. LinksTuple.app (https://tuple.app) - The best app for pair programmingThorsten's website (https://thorstenball.com) - Where you can find his books, blog, and other podcast appearancesZed (https://zed.dev) - The editor Thorsten is working onKey TakeawaysCultivating a diverse skill set can lead to unique opportunities and make you a valuable asset in a company.Evidence of competence, such as published work or open-source contributions, can significantly impact your chances of getting hired.Soft skills, such as communication and problem-solving, are essential for success in engineering roles.Taking initiative and adding value beyond your job description can make you stand out and contribute to the growth of a company.Interviews should be seen as a chance to demonstrate your skills and fit within a company's culture, rather than just answering questions. Visual cues and real-time interaction are important in conversations to gauge resonance and maintain engagement.Different business models exist in the tech industry, and investment can provide the time and resources needed for product development.Building high-quality products in open source requires a focus on performance, quality, and attention to detail.The landscape of text editors and funding is complex, with various models and approaches.Working on a quality product with a talented team can be fulfilling and contribute to personal growth.Noticing and writing about interesting ideas can enhance creativity and lead to new insights.Chapters(00:00) - Introduction and Background (00:21) - Combining Software Engineering and Content Production (04:41) - The Power of a Diverse Skill Set (07:40) - Creating Valuable Content (11:53) - Taking Initiative and Adding Value (18:47) - Reaching Out and Getting Hired (20:42) - The Power of Evidence of Competence (21:39) - The Myth of Not Hiring (25:35) - The Importance of Leaving Evidence (28:06) - Resumes and Demonstrating Competence (30:56) - Interviews as a Vibe Check (32:38) - The Bias in Interviews (33:55) - Hiring Process and Competence (34:22) - No Foolproof Hiring Process (35:20) - Evidence of Ability (37:00) - Accepting the Hiring Game (39:54) - Marketing and Self-Promotion (44:10) - Zed's Journey and User Availability (51:02) - Collaboration in Zed (56:02) - The Magic of Audio Calls (58:49) - The Intimacy of Voice-Only Communication (01:01:16) - The Distraction of Self-View in Video Calls (01:02:43) - The Importance of Visual Cues in Conversations (01:03:36) - The Value of Real-Time Interaction (01:05:34) - The Deep Knowledge and Complexity of Vim (01:06:00) - The Benefits of Noticing and Writing About Interesting Ideas (01:09:40) - The Habit of Writing and Its Impact on Thinking

Tras una larga pausa vuelvo a las grabaciones del podcast. Para esta nueva etapa quiero hablar de la estupenda charla ofrecida por Ben Orenstein en la conferencia Laracon US 2023 titulada  "Predictable Mistakes of the Developer-Turned-Founder". En esta presentación Ben aborda los retos habituales a los que se enfrentan los desarrolladores que pasan a desempeñar el papel de fundador. Desde su propia experiencia en su empresa Tuple de varios años, Ben Orenstein ofrece valiosos consejos sobre cómo superar estos desafíos y fomentar una transición exitosa en el mundo del emprendimiento. Entre los errores que nos comenta Ben en su charla comentaré los siguientes: Empezar con la filosofía del SAAS en mente. Escoger una mala idea. Enfocarse en vender clientes individuales en lugar de a buenos negocios. Venderle a negocios baratos. Asumir que no debe existir competencia en el mercado. Escribir código. No enfocarse en un entorno deseable como profesional. No hacer email marketing. No hacer buen pricing. No atender la experiencia de usuario desde el principio. Sobreconstruir soluciones. No ser autosuficiente financieramente y contar con inversores externos sin conexión. No ir acompañado y no hacer networking. Os recomiendo ver la charla completa en YouTube donde Ben explica con detalle todos estos puntos. Espero tus comentarios y participación en este episodio. ¡Gracias!

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

In this conversation, Fable and Ben dig deep on building a technical career that balances programming and company leadership. Fable shares their experience working at Stripe and the different roles they have held, including being a technical advisor to the CTO. They also discuss Fable's career move from being a hands-on programmer to role where less hands-on coding is required, Fable's take on "code crimes", and how to find enjoyment and fulfillment in solving complex problems.LinksTuple.app - The best app for pair programmingStripe - The company Fable works atRuby Kaigi - An annual conference dedicated to the Ruby programming language.Sidekiq - A simple, efficient background processing library for RubySorbet - A fast, powerful type checker designed for Ruby.YubiKey - A hardware device designed for high-security two-factor authentication.Key TakeawaysMaking connections and friendships at conferences can be valuable in the programming community.Debugging and problem-solving skills are crucial for software engineers.Being willing to learn and work with different programming languages can enhance your skills.Prototyping and spiking can be effective ways to test and develop new ideas.Chapters(00:00) - Introduction and Conference Interaction (00:38) - Making Friends at Conferences (04:13) - Work at Stripe (06:17) - Becoming a Staff Engineer (06:53) - Getting Good at Programming (08:46) - Debugging and Problem Solving (11:22) - Working with C and C++ (13:13) - Debugging with Print Statements and Debuggers (17:06) - Prototyping and Spiking (24:11) - Technical Advisor to the CTO (27:26) - Coding Hill to Die On (29:52) - Workflow Optimization (36:53) - Coding vs Non-Coding Time (39:08) - Transition to Leadership (41:07) - Motivation and Impact (42:13) - Love for Programming (44:14) - Coding Style: Short Methods and Small Classes (48:48) - Personal Style and Code Crimes (52:18) - Commercial Open Source (56:08) - Getting Involved in Open Source (01:04:52) - Wrap-up

In this episode, Ben interviews Josh Pigford, founder of Maybe.co, about the company's journey from VC-backed startup -> closed startup -> open source project -> funded open source project. They discuss JavaScript and Rails trade-offs, the challenges of building a personal finance software, and the operational difficulties of building a business based on open source software.LinksTuple.app - The best app for pair programmingMaybe.co - The fintech startup Josh foundedNodeJS - The starting framework for Maybe.coRuby on Rails - The new framework for Maybe.coKey TakeawaysChoosing the right tech stack is crucial for the success of a project.Running out of runway can force difficult decisions and pivots.Making a codebase public can generate interest and community engagement.Replacing third-party dependencies can be challenging but necessary.Rebuilding a software project requires careful planning and decision-making. Building a personal finance app involves challenges such as managing pull requests and issues in open source development.Transitioning to Rails can provide a more stable and efficient framework for building a complex application.The decision to rewrite the app from scratch allows for better decision-making and faster progress.Targeting Mint users with a budgeting tool presents an opportunity to capitalize on a fragmented market.Detangled, a project that simplifies legal documents, has the potential for commercial success. Moonshot ideas can be exciting and worth pursuing, even if the specific angle is unclear.ChatGPT has the potential to generate usable results, either through heavily massaged prompts or prewritten blocks.Tools like detangle can augment conversations with lawyers, providing insights and helping users know what questions to ask.There are commercial opportunities in selling services like detangle to companies that don't have full-time counsel.Finding the right balance between passion and traction is important when deciding which projects to pursue.Chapters(00:00) - Introduction (01:21) - Making the Codebase Public (07:21) - Community Engagement and Pull Requests (12:17) - Ripping Out Functionality (15:03) - Replacing Data Aggregator (16:10) - Building a Personal Finance App (17:39) - Challenges of Open Source Development (21:08) - Managing Pull Requests and Issues (23:35) - Struggles with React Next.js (27:45) - Choosing Rails for Development (32:40) - Targeting Mint Users with Budgeting Tool (35:45) - Modular Use Cases (38:53) - Open Source Contributions and Bounties (40:47) - Next Steps (45:16) - Detangled: Simplifying Legal Documents (48:32) - Exploring Moonshot Ideas (48:58) - The Potential of ChatGPT (49:45) - Augmenting Conversations with Lawyers (50:21) - Commercial Opportunities (50:53) - Balancing Passion and Traction (51:20) - Closing Remarks

In this episode we get the chance to interview Ben Orenstein: A person who probably doesn't need much of an introduction to our listeners. This episode should be special. Ben's journey from developer to entrepreneur exemplifies the path many in our audience aspire to tread. With a keen eye for opportunities and a deep understanding of the software industry's nuances, Ben's insights are invaluable for anyone looking to leverage their technical skills beyond the keyboard. Join us as we discuss strategies, challenges, and the mindset required to thrive in the competitive landscape of tech entrepreneurship.Links:TwitterTupleTuple PodcastPersonal siteHackers Inc Podcast"Predictable Mistakes of the Developer-Turned-Founder" - Laracon talk

In this conversation, Ben interviews Caleb Porzio, the creator of AlpineJS and Laravel Livewire. The discussion ranges from discussions about life in general to specific testing practices and which notebook Caleb uses.LinksTuple.app - The best app for pair programmingAlpineJS Laravel Livewire Caleb's VSCode Course TakeawaysApply core truths to life outside of programming.Find ways to make difficult tasks easier.Change your environment to support your goals.Value tests as much as, if not more than, the code itself.Keep methods and functions short for better code quality.Embrace your strengths and delegate tasks that don't bring you joy.Focus on the meaty tasks that excite you.Consider rewrites carefully and prioritize other solutions first.Pull down unfamiliar code and interact with it to understand it better.Start the day with tasks that align with your goals and priorities.Chapters(00:00) - Introduction and Background (03:51) - Overview of LiveWire and Alpine (12:09) - Caleb's Programming Style (20:09) - Functional vs Object-Oriented Programming (25:39) - The Appeal of Functional Programming (32:01) - The Challenges of Learning Object-Oriented Programming (33:06) - Memory Allocation and Functional Languages (36:30) - Starting Complicated Projects (40:10) - Writing Blog Posts as Problem-Solving (42:30) - Core Beliefs (48:21) - Materials (49:20) - Getting into the Zone (51:14) - The Value of Tests Over Code (55:27) - Transitioning to Non-Typical Apps (01:03:00) - Radical Practices at Tuple (01:05:50) - Managing Pull Requests and Code Reviews (01:06:33) - Starting the Day and Prioritizing Tasks (01:07:41) - Balancing Maintenance and Long-Term Goals (01:09:52) - Finding Motivation for Maintenance Tasks (01:10:50) - Embracing Strengths and Delegating Weaknesses (01:11:46) - Continuous Improvement and Learning (01:14:19) - Favorite Tools and Productivity Hacks (01:19:07) - Core Beliefs and Values in Coding (01:21:19) - Benefits of Short Methods and Single File Principle (01:21:57) - Approaching Unfamiliar Code (01:22:51) - The Pros and Cons of Rewrites (01:23:46) - Final Thoughts and Passion for Coding

In this conversation, Ben interviews Taylor Otwell, the creator of Laravel. They discuss everything from the age-old argument of tabs vs. spaces to the origins of Laravel and how Taylor has turned it into a thriving, sustainable business.Links:Laravel, the framework Taylor createdTuple, used by the Laravel team to collaboratesTakeawaysCoding preferences and philosophies can vary among developers and programming ecosystems.Maintaining backwards compatibility is important for frameworks with a large user base.Clean code can be subjective and depends on the specific needs and goals of a project.Testing is crucial for shipping software with confidence. When starting a new project, consider writing documentation first to iron out any potential issues and ensure a user-centric perspective.Focus on high-level testing, such as feature-level or controller-level tests, to gain confidence in the functionality of your code.Challenge assumptions and ask questions to improve the quality of your code and avoid unnecessary complexity.Believe in the potential of your project and raise your ambitions to achieve greater success.Building a business around open source can be a sustainable model if you create commercial products that complement and support the open source project.Chapters(00:00) - Tabs or Spaces? (08:00) - Shells (10:46) - Minimalism in Coding (17:24) - Stripe and Their API (22:41) - Aesthetics (25:09) - A Coding Hill You Would Die On (28:09) - Clean Code (33:38) - Testing (40:30) - Personal Involvement With Code (45:00) - Notes and Manifestos (49:09) - Skill Over Time (51:49) - Ian Landsman and Laravel (55:49) - Businesses Based on Open Source

In this episode, Adam and Ben sit down to evaluate how things went in 2023 in their business and personal lives. The dudes share kind of a lot in this one! More personal flavor than usual. Lots about fitness, mental health, gathering, and rascally-ness. Timestamps(00:00) - Ben and Adam review 2023 (03:17) - Ben wants to be more of a rascal (07:58) - Health update (30:06) - Ben wants to prioritize creating "gatherings" (39:06) - Following your intuition (52:49) - Tailwind Labs business review (01:07:37) - Productivity (01:20:11) - 2023 lowlights — things to improve in 2024 LinksAdam on TwitterBen on Twitter

In this episode, Adam and Ben talk through the Tailwind Labs business model. Is Tailwind UI the best way for the company to make money? Or is there a different model where incentives are better aligned with growing the Tailwind CSS community as a whole? One potential model is offering a marketplace for templates and UI kits. Timestamps(00:00) - Black Friday (04:58) - Continuously improving stuff (12:50) - Tuple Rooms (16:15) - Revisiting the Tailwind Labs business model (27:28) - Brainstorming a Tailwind CSS marketplace (39:54) - Should Tailwind Labs build a SaaS? LinksAdam on TwitterBen on Twitter

In this episode, Adam and Ben catch up on recent events at Tailwind Labs and Tuple. Adam spoke at Rails World and the impromptu Tailwind CSS meetup in Amsterdam. Ben shares his learnings from some recent feature launches at Tuple.Timestamps(00:00) - Burpees (02:47) - Rails World + Tailwind CSS Amsterdam meetup (11:27) - Launching Tuple Triggers (25:57) - Tuple App Veil LinksAdam on TwitterBen on TwitterAdam Wathan - Tailwind CSS: It looks awful, and it works - Rails World 2023Tuple TriggersTuple App Veil

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

Adam wants to start the process of growing the team at Tailwind Labs, but knowing exactly who, when, and how to hire people (and have them actually work out) is a lot harder than expected. In this episode, he sits down with Jason Fried, founder and CEO of 37signals, to get all of Jason's best advice about hiring.Timestamps(00:00) - Talking hiring with Jason Fried (02:04) - Knowing when it's time to hire (04:57) - Grouping different responsibilities into single roles (11:49) - Example: Delegating some of Adam's responsibilities at Tailwind Labs (20:47) - Hiring to get more done vs. free up more time (23:58) - Stuff Jason has successfully delegated at 37signals (31:09) - Hard truths about hiring and growing a company (40:39) - Patrick Collison — Fast (44:13) - Anxiety about making bad hires (53:28) - Letting people go (54:55) - Jason's advice on making new hires successful (58:49) - Giving feedback (01:01:32) - Assessing good judgment (01:05:18) - Reviewing candidates LinksAdam on TwitterBen on TwitterJason on TwitterPatrick Collison — Fast

In this episode, I'm joined by a special guest, Ben Ornstein, one of my Ruby heroes. I may fan-boy a bit as I express my admiration for Tuple, a tool I love. Together, we dive deep into Tuple's journey, starting from its inception and delving into the creative problem-solving and ingenuity behind its design and development. Ben also reveals his transition from CEO to Head of Product.  We discuss the fresh perspective on team collaboration methods and product development this change offers. We explore how feedback loops and Agile practices play a pivotal role in Tuple's continuous evolution. Along the way, we also reflect on the 'My Life in Weeks' poster, which serves as a stark reminder of the fleeting nature of our time on Earth. This episode is a roller-coaster of insights, trivia, and reflections that will hopefully leave you feeling wiser and more contemplative.Links:@r00k on TwitterTuple (aka my favorite way to pair)'My Life in Weeks' poster'A Short History of Nearly Everything' by Bill BrysonSupport the showReady to start your own podcast?This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.SponsorsA big thanks to OBLSK for being the very first sponsor of the show!

When you're running a small company, hiring is simultaneously your highest leverage opportunity and the scariest thing ever. In this episode, Adam and Ben share some lessons learned, how they think about hiring for their teams now, and talk through some of the things they're still trying to figure out how to get right.Discuss this episode on Twitter →Timestamps(00:00) - Hiring (02:02) - Why hire at all? (06:41) - Avoiding hiring altogether (11:44) - Vetting people (24:45) - Finding people (36:22) - How Ben got recruited at Thoughtbot (37:53) - Evaluating hires (43:23) - Fears and anxieties around hiring (50:50) - Unfair hiring advantages (57:36) - Levels of management LinksAdam on TwitterBen on Twitter

Enterprise sales gets a bad rap amongst indie founders, but at Tuple it's become an important part of their business model. In this episode, Ben shares all his tips and tricks on how to sell to enterprise customers as a small startup without letting it slow you down.Discuss this episode on Twitter →Timestamps(00:00) - Ben's notes on enterprise sales (02:58) - Ben's first time (04:56) - Tactic: Build a product that can grow bottom-up (07:12) - Tactic: Ask buyers to answer their own questions (08:34) - Tactic: Say no to more than you think (16:11) - Tactic: Your pricing should make you uncomfortable (25:38) - Tactic: Charge more for SAML single sign-on (27:50) - Tactic: Don't sign something without charging a lot (28:34) - Tactic: Put an expiration date on your quotes (29:12) - Tactic: Dodge pricing pushback with quarterly payments (31:06) - Tactic: Make sure you lose some deals because of price (33:26) - How procurement works (37:54) - How important is enterprise sales for Tuple? (47:59) - Tactic: Ask procurement, "what helps this deal get done faster" (49:49) - Tactic: Have a /security page on your website (53:07) - Tactic: Use Y Combinator's sales agreement template (55:47) - Tactic: You probably won't be sued LinksAdam on TwitterBen on TwitterTuple's /security pageY Combinator — Sales Agreement

After over 20 years in business and despite being responsible for a larger-than-ever team, David still finds plenty of time to get his hands in the code and build new products himself. We run significantly younger companies and significantly smaller teams and even we can't seem to find the space to do that, so we talked to DHH about how he makes it possible.Discuss this episode on Twitter →Timestamps(00:00) - “Why the fuck did I do this?” (06:20) - What is minimalist management? (10:56) - Should you need to be a trained life coach to be allowed to hire people? (16:12) - Using systems to provide career progression guidance (18:50) - What do David's days usually look like? (27:13) - What are David's responsibilities at Basecamp, and what are people counting on him for day-to-day? (29:38) - How David and Jason use their Shape Up framework to give people more responsibility at Basecamp (36:30) - Getting comfortable with being uncomfortable when giving people more responsibility (45:54) - Letting people go when they can't live up to the responsibility (47:14) - What systems do the 37signals team rely on that that haven't already been talked about publicly? (50:04) - Letting people make decisions you may have to correct and being comfortable correcting them (55:03) - Radical candor and redirecting feedback (01:00:55) - How to say no to opportunities and being willing to take risks (01:11:22) - Learning to stop worrying when you finally do succeed LinksAdamBenDavid

Last summer, Tailwind UI moved from selling individual content packages and upsells to a one-time purchase, lifetime access pricing model. Since then, the business has doubled. Having seen this in action, Adam recently convinced his friends Sam and Ryan to try lifetime pricing for their product Build UI, and the results are starting to come in. In this episode, Adam and Ben dive deep into the world of lifetime pricing, why it's not something to be afraid of, and how it can be an absolute game-changer for the right type of business.Discuss this episode on Twitter →Timestamps(00:00) - Intro (00:14) - Why are we talking about this? (03:28) - Moving from package pricing to lifetime all-access pricing for Tailwind UI (06:03) - What about when you run out of new customers? (10:17) - "Everything You've Learned at MicroConf is Wrong" by Chad DeShon (13:33) - The myth of starting from zero every month (16:04) - Would Tailwind UI work as a subscription model? (18:09) - Characteristics of a lifetime-suitable product (20:50) - Subscription LTV vs. lifetime pricing (22:47) - Subscription friction and the death of the impulse purchase (25:42) - The brutality of churn in content businesses (27:21) - Why your lifetime price can actually be higher than your subscription LTV (29:01) - Ben's experience running Upcase at thoughtbot (32:42) - The hidden costs of the content treadmill (36:20) - Hitting a subscription plateau with Upcase (38:34) - Cookie Clicker game — how to make perceived value go up over time (42:31) - Why aspirational, impulsive purchases are more likely with lifetime deals (45:22) - Pricing decisions aren't forever (49:13) - Turning Build UI from a grind into an instant success by flipping the switch on pricing (54:17) - Using lifetime pricing to buy yourself flexibility and time to focus LinksAdam on TwitterBen on TwitterTailwind UI all-accessEverything You've Learned at MicroConf is Wrong, Chad DeShon's lighting talk at MicroConf Growth 2018Build UI, Sam and Ryan's new UI training site that recently switched to lifetime pricing

Jason Cohen's talk “Designing the Ideal Bootstrapped Business” from 2013 is a classic in the bootstrapper canon. In this episode, Jason joins Adam and Ben to see how the talk holds up a decade after its creation. Timestamps00:00 Intro00:27 Designing the ideal bootstrapped business06:53 Recurring revenue vs one-off sales13:30 Getting all the LTV up front18:31 Product validation24:56 Creating a cash machine26:05 Where does growth come from?41:25 Annual prepays46:41 Increasing your prices51:56 What new advice is there since this talk?59:00 What about freemium?01:03:39 What happens next?01:08:58 Picking an idea that's compatible with the life you want to live01:12:16 Ideas for TailwindLinksAdamBenJason

Ben Orenstein (Tuple) and Adam Wathan (Tailwind CSS) are back on the mics. Today they reflect on 2022 and lessons they've learned. Ben has some thoughts on delegation, priorities and enterprise sales, while Adam explains how he made time for proof of concepts and has figured a way to actually follow his to-do list.Timestamps00:00 Intro02:11 Setting priorities05:11 Shaping up08:27 Don't allocate everyone to every project15:46 Top down management17:13 Delegation gone wrong can still be a success22:06 Don't make your to-do list a chore list24:00 Declaring calendar bankruptcy27:43 Don't make promises future you has to pay for30:09 Make decisions quickly32:54 Making time for proofs of concept37:25 Bluffing in enterprise sales40:38 Doing things the way you want to, as much as you can afford toLinksAdamBen

“How come Dave Grohl is still playing guitar and writing songs and singing but I'm filling out DMCA takedown notices, answering customer support emails and responding to GitHub issues?” Timestamps00:00 Intro03:05 Bringing on a band manager07:34 Why the band metaphor works11:54 Make things for your fans, not for your critics14:49 Always do the things you want to do18:04 Turning over your rep over time19:33 A band needs a frontman22:14 Showing behind the scenes25:23 Doing one thing at a time30:57 Don't interview people, audition them35:38 We don't make movies to make money, we make money to make moviesLinksAdamBen

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.

The Code Quality Challenge (https://tuple.app/code-quality-challenge) Tuple's open CTO position (https://tuple.app/jobs/cto) Kevin Shen's Dream Studio Course (https://dreamstudiocourse.com/)

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

In episode 614, Rob Walling chats with fan favorite Derrick Reimer. They start out by talking about Derrick's decision to take a sabbatical from The Art of Product podcast after co-hosting it with Ben Orenstein for more than 5 years. Then, they answer a handful of listener questions, including when to quit your day job to […]Click the icon below to listen.  

Aaron Francis (Tuple's Marketing Engineer) drops by for advice on his non-Tuple project, a query builder for Rails and Laravel called Refine.

Penelope Phippen drops by and encourages Ben to set, like, even a single goal.

Talking with Dr. Sherry Walling about dealing with mental health personally and how to help people around you who may be struggling.

Tuple launched a new marketing experiment this week. Derrick is continuing work on migrating SavvyCal to new hosting infrastructure.

The Tuple team had their first filming session for the meta-documentary about their marketing experiments. Derrick is awaiting results from the latest SavvyCal funnel experiments.

Ben and Derrick catch up on all things Tuple (https://tuple.app/) and SavvyCal (https://savvycal.com/?via=drfgar). Ben recently raised prices for Tuple. Derrick is experimenting with major funnel changes for SavvyCal.

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

Derrick is launching a bunch of SavvyCal features this month, including a Close integration and meeting polls. Ben has had good experiences lately talking to customers.

Stripe's Technical Advisor to the CTO, Penelope Phippen (https://www.linkedin.com/in/penelope-phippen-4103142b/) stops by and Ben tries to get her to divulge company secrets.

Ben and Derrick chat through a cool new feature Tuple (https://tuple.app/) is shaping up. They also discuss Tuple's ambitious marketing bets.

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.

Ben and the Tuple team have hit a good shipping stride lately. Derrick and team are nearing completion on a few large SavvyCal initiatives. The guys reflect on MicroConf and the nature of dispensing advice.

Derrick and Ben share updates from the Castos recording booth at MicroConf Growth.

Follow Ben: https://twitter.com/r00kCheck out Tuple: https://tuple.appDid your latest AWS bill give you a heart attack? CloudForecast sends you daily transparent reports that help you understand your AWS costs, find any overspends, and promote opportunities to save costs. CloudForecast takes complicated data and produces accurate, presentable reports so you can share stats quickly and make strategic decisions swiftly. With communication integrations like Slack, Microsoft Teams, and email to share insights, you can go from managing your AWS spend in hours to seconds. Start a 30-day free trial today! No credit card is required to get started at CloudForecast.io. 

Our favorite Canadian drops by to talk mobility, fancy A/V setups, what's next for Tailwind UI, and how we'll never find peace of mind.

Ben and Derrick riff on a variety of topics, including coffee brewing, retreats, MicroConf, design, finding business ideas, and interesting subreddits. Links: Sweet Maria's (https://www.sweetmarias.com/) MicroConf (https://microconf.com/) Finding My Next Bootstrapped Business Idea (https://www.derrickreimer.com/essays/2019/05/28/finding-my-next-bootstrapped-business-idea.html) The Stair Step Approach to Bootstrapping (https://robwalling.com/2015/03/26/the-stairstep-approach-to-bootstrapping/) fatFIRE (https://www.reddit.com/r/fatFIRE/) OneBag - The Art of Minimalist Travel (https://www.reddit.com/r/onebag/)

The Tuple team has recently grown by three team members! Ben is looking forward to getting the Linux client out the door in the next month. Derrick is staying busy moving SavvyCal forward and bringing his new developer into the app.

Ben talks to Brian Lovin, a designer, podcaster, writer, and software tinkerer.