Podcasts about Sybase

Patrick Lencioni is co-founder and President of The Table Group and is the pioneer of the organizational health movement. He is the author of 13 books, which have sold over 8 million copies and been translated into more than 30 languages. As President of the Table Group, Pat spends his time speaking and writing about leadership, teamwork, and organizational health and consulting with executives and their teams. Prior to founding the firm in 1997, Pat worked at Bain & Company, Oracle Corporation and Sybase. On this classic episode, his second appearance on ⁠the Elevate Podcast⁠, Patrick returned to the show to discuss the role company leaders should play in sociopolitical issues, how to set proper expectations with employees and customers about where a company stands on social issues, and why leaning on values is as crucial as ever in leadership today. Special Thanks to the Sponsors of the Elevate Podcast Shopify: Sign up for your $1/month trial period at ⁠shopify.com/elevate⁠ Indeed: Get a $75 sponsored job credit to boost your job's visibility at ⁠Indeed.com/elevate⁠. NPM Tech Unheard Podcast: Tune into Tech Unheard from Arm and NPM—wherever you get your podcasts. Northwest Registered Agent: Don't wait—protect your privacy, build your brand, and set up your business in just 10 clicks and 10 minutes! Visit ⁠https://northwestregisteredagent.com/elevate⁠ today. Learn more about your ad choices. Visit megaphone.fm/adchoices

In a new season of the Oracle University Podcast, Lois Houston and Nikita Abraham dive into the world of Oracle GoldenGate 23ai, a cutting-edge software solution for data management. They are joined by Nick Wagner, a seasoned expert in database replication, who provides a comprehensive overview of this powerful tool.   Nick highlights GoldenGate's ability to ensure continuous operations by efficiently moving data between databases and platforms with minimal overhead. He emphasizes its role in enabling real-time analytics, enhancing data security, and reducing costs by offloading data to low-cost hardware. The discussion also covers GoldenGate's role in facilitating data sharing, improving operational efficiency, and reducing downtime during outages.   Oracle GoldenGate 23ai: Fundamentals: https://mylearn.oracle.com/ou/course/oracle-goldengate-23ai-fundamentals/145884/237273 Oracle University Learning Community: https://education.oracle.com/ou-community LinkedIn: https://www.linkedin.com/showcase/oracle-university/ X: https://x.com/Oracle_Edu   Special thanks to Arijit Ghosh, David Wright, Kris-Ann Nansen, Radhika Banka, and the OU Studio Team for helping us create this episode. ---------------------------------------------------------------   Episode Transcript: 00:00 Welcome to the Oracle University Podcast, the first stop on your cloud journey. During this series of informative podcasts, we'll bring you foundational training on the most popular Oracle technologies. Let's get started! 00:25 Nikita: Welcome to the Oracle University Podcast! I'm Nikita Abraham, Team Lead: Editorial Services with Oracle University, and with me is Lois Houston: Director of Innovation Programs. Lois: Hi everyone! Welcome to a new season of the podcast. This time, we're focusing on the fundamentals of Oracle GoldenGate. Oracle GoldenGate helps organizations manage and synchronize their data across diverse systems and databases in real time.  And with the new Oracle GoldenGate 23ai release, we'll uncover the latest innovations and features that empower businesses to make the most of their data. Nikita: Taking us through this is Nick Wagner, Senior Director of Product Management for Oracle GoldenGate. He's been doing database replication for about 25 years and has been focused on GoldenGate on and off for about 20 of those years.  01:18 Lois: In today's episode, we'll ask Nick to give us a general overview of the product, along with some use cases and benefits. Hi Nick! To start with, why do customers need GoldenGate? Nick: Well, it delivers continuous operations, being able to continuously move data from one database to another database or data platform in efficiently and a high-speed manner, and it does this with very low overhead. Almost all the GoldenGate environments use transaction logs to pull the data out of the system, so we're not creating any additional triggers or very little overhead on that source system. GoldenGate can also enable real-time analytics, being able to pull data from all these different databases and move them into your analytics system in real time can improve the value that those analytics systems provide. Being able to do real-time statistics and analysis of that data within those high-performance custom environments is really important. 02:13 Nikita: Does it offer any benefits in terms of cost?  Nick: GoldenGate can also lower IT costs. A lot of times people run these massive OLTP databases, and they are running reporting in those same systems. With GoldenGate, you can offload some of the data or all the data to a low-cost commodity hardware where you can then run the reports on that other system. So, this way, you can get back that performance on the OLTP system, while at the same time optimizing your reporting environment for those long running reports. You can improve efficiencies and reduce risks. Being able to reduce the amount of downtime during planned and unplanned outages can really make a big benefit to the overall operational efficiencies of your company.  02:54 Nikita: What about when it comes to data sharing and data security? Nick: You can also reduce barriers to data sharing. Being able to pull subsets of data, or just specific pieces of data out of a production database and move it to the team or to the group that needs that information in real time is very important. And it also protects the security of your data by only moving in the information that they need and not the entire database. It also provides extensibility and flexibility, being able to support multiple different replication topologies and architectures. 03:24 Lois: Can you tell us about some of the use cases of GoldenGate? Where does GoldenGate truly shine?  Nick: Some of the more traditional use cases of GoldenGate include use within the multicloud fabric. Within a multicloud fabric, this essentially means that GoldenGate can replicate data between on-premise environments, within cloud environments, or hybrid, cloud to on-premise, on-premise to cloud, or even within multiple clouds. So, you can move data from AWS to Azure to OCI. You can also move between the systems themselves, so you don't have to use the same database in all the different clouds. For example, if you wanted to move data from AWS Postgres into Oracle running in OCI, you can do that using Oracle GoldenGate. We also support maximum availability architectures. And so, there's a lot of different use cases here, but primarily geared around reducing your recovery point objective and recovery time objective. 04:20 Lois: Ah, reducing RPO and RTO. That must have a significant advantage for the customer, right? Nick: So, reducing your RPO and RTO allows you to take advantage of some of the benefits of GoldenGate, being able to do active-active replication, being able to set up GoldenGate for high availability, real-time failover, and it can augment your active Data Guard and Data Guard configuration. So, a lot of times GoldenGate is used within Oracle's maximum availability architecture platinum tier level of replication, which means that at that point you've got lots of different capabilities within the Oracle Database itself. But to help eke out that last little bit of high availability, you want to set up an active-active environment with GoldenGate to really get true zero RPO and RTO. GoldenGate can also be used for data offloading and data hubs. Being able to pull data from one or more source systems and move it into a data hub, or into a data warehouse for your operational reporting. This could also be your analytics environment too. 05:22 Nikita: Does GoldenGate support online migrations? Nick: In fact, a lot of companies actually get started in GoldenGate by doing a migration from one platform to another. Now, these don't even have to be something as complex as going from one database like a DB2 on-premise into an Oracle on OCI, it could even be simple migrations. A lot of times doing something like a major application or a major database version upgrade is going to take downtime on that production system. You can use GoldenGate to eliminate that downtime. So this could be going from Oracle 19c to Oracle 23ai, or going from application version 1.0 to application version 2.0, because GoldenGate can do the transformation between the different application schemas. You can use GoldenGate to migrate your database from on premise into the cloud with no downtime as well. We also support real-time analytic feeds, being able to go from multiple databases, not only those on premise, but being able to pull information from different SaaS applications inside of OCI and move it to your different analytic systems. And then, of course, we also have the ability to stream events and analytics within GoldenGate itself.  06:34 Lois: Let's move on to the various topologies supported by GoldenGate. I know GoldenGate supports many different platforms and can be used with just about any database. Nick: This first layer of topologies is what we usually consider relational database topologies. And so this would be moving data from Oracle to Oracle, Postgres to Oracle, Sybase to SQL Server, a lot of different types of databases. So the first architecture would be unidirectional. This is replicating from one source to one target. You can do this for reporting. If I wanted to offload some reports into another server, I can go ahead and do that using GoldenGate. I can replicate the entire database or just a subset of tables. I can also set up GoldenGate for bidirectional, and this is what I want to set up GoldenGate for something like high availability. So in the event that one of the servers crashes, I can almost immediately reconnect my users to the other system. And that almost immediately depends on the amount of latency that GoldenGate has at that time. So a typical latency is anywhere from 3 to 6 seconds. So after that primary system fails, I can reconnect my users to the other system in 3 to 6 seconds. And I can do that because as GoldenGate's applying data into that target database, that target system is already open for read and write activity. GoldenGate is just another user connecting in issuing DML operations, and so it makes that failover time very low. 07:59 Nikita: Ok…If you can get it down to 3 to 6 seconds, can you bring it down to zero? Like zero failover time?   Nick: That's the next topology, which is active-active. And in this scenario, all servers are read/write all at the same time and all available for user activity. And you can do multiple topologies with this as well. You can do a mesh architecture, which is where every server talks to every other server. This works really well for 2, 3, 4, maybe even 5 environments, but when you get beyond that, having every server communicate with every other server can get a little complex. And so at that point we start looking at doing what we call a hub and spoke architecture, where we have lots of different spokes. At the end of each spoke is a read/write database, and then those communicate with a hub. So any change that happens on one spoke gets sent into the hub, and then from the hub it gets sent out to all the other spokes. And through that architecture, it allows you to really scale up your environments. We have customers that are doing up to 150 spokes within that hub architecture. Within active-active replication as well, we can do conflict detection and resolution, which means that if two users modify the same row on two different systems, GoldenGate can actually determine that there was an issue with that and determine what user wins or which row change wins, which is extremely important when doing active-active replication. And this means that if one of those systems fails, there is no downtime when you switch your users to another active system because it's already available for activity and ready to go. 09:35 Lois: Wow, that's fantastic. Ok, tell us more about the topologies. Nick: GoldenGate can do other things like broadcast, sending data from one system to multiple systems, or many to one as far as consolidation. We can also do cascading replication, so when data moves from one environment that GoldenGate is replicating into another environment that GoldenGate is replicating. By default, we ignore all of our own transactions. But there's actually a toggle switch that you can flip that says, hey, GoldenGate, even though you wrote that data into that database, still push it on to the next system. And then of course, we can also do distribution of data, and this is more like moving data from a relational database into something like a Kafka topic or a JMS queue or into some messaging service. 10:24 Raise your game with the Oracle Cloud Applications skills challenge. Get free training on Oracle Fusion Cloud Applications, Oracle Modern Best Practice, and Oracle Cloud Success Navigator. Pass the free Oracle Fusion Cloud Foundations Associate exam to earn a Foundations Associate certification. Plus, there's a chance to win awards and prizes throughout the challenge! What are you waiting for? Join the challenge today by visiting visit oracle.com/education. 10:58 Nikita: Welcome back! Nick, does GoldenGate also have nonrelational capabilities?  Nick: We have a number of nonrelational replication events in topologies as well. This includes things like data lake ingestion and streaming ingestion, being able to move data and data objects from these different relational database platforms into data lakes and into these streaming systems where you can run analytics on them and run reports. We can also do cloud ingestion, being able to move data from these databases into different cloud environments. And this is not only just moving it into relational databases with those clouds, but also their data lakes and data fabrics. 11:38 Lois: You mentioned a messaging service earlier. Can you tell us more about that? Nick: Messaging replication is also possible. So we can actually capture from things like messaging systems like Kafka Connect and JMS, replicate that into a relational data, or simply stream it into another environment. We also support NoSQL replication, being able to capture from MongoDB and replicate it onto another MongoDB for high availability or disaster recovery, or simply into any other system. 12:06 Nikita: I see. And is there any integration with a customer's SaaS applications? Nick: GoldenGate also supports a number of different OCI SaaS applications. And so a lot of these different applications like Oracle Financials Fusion, Oracle Transportation Management, they all have GoldenGate built under the covers and can be enabled with a flag that you can actually have that data sent out to your other GoldenGate environment. So you can actually subscribe to changes that are happening in these other systems with very little overhead. And then of course, we have event processing and analytics, and this is the final topology or flexibility within GoldenGate itself. And this is being able to push data through data pipelines, doing data transformations. GoldenGate is not an ETL tool, but it can do row-level transformation and row-level filtering.  12:55 Lois: Are there integrations offered by Oracle GoldenGate in automation and artificial intelligence? Nick: We can do time series analysis and geofencing using the GoldenGate Stream Analytics product. It allows you to actually do real time analysis and time series analysis on data as it flows through the GoldenGate trails. And then that same product, the GoldenGate Stream Analytics, can then take the data and move it to predictive analytics, where you can run MML on it, or ONNX or other Spark-type technologies and do real-time analysis and AI on that information as it's flowing through.  13:29 Nikita: So, GoldenGate is extremely flexible. And given Oracle's focus on integrating AI into its product portfolio, what about GoldenGate? Does it offer any AI-related features, especially since the product name has “23ai” in it? Nick: With the advent of Oracle GoldenGate 23ai, it's one of the two products at this point that has the AI moniker at Oracle. Oracle Database 23ai also has it, and that means that we actually do stuff with AI. So the Oracle GoldenGate product can actually capture vectors from databases like MySQL HeatWave, Postgres using pgvector, which includes things like AlloyDB, Amazon RDS Postgres, Aurora Postgres. We can also replicate data into Elasticsearch and OpenSearch, or if the data is using vectors within OCI or the Oracle Database itself. So GoldenGate can be used for a number of things here. The first one is being able to migrate vectors into the Oracle Database. So if you're using something like Postgres, MySQL, and you want to migrate the vector information into the Oracle Database, you can. Now one thing to keep in mind here is a vector is oftentimes like a GPS coordinate. So if I need to know the GPS coordinates of Austin, Texas, I can put in a latitude and longitude and it will give me the GPS coordinates of a building within that city. But if I also need to know the altitude of that same building, well, that's going to be a different algorithm. And GoldenGate and replicating vectors is the same way. When you create a vector, it's essentially just creating a bunch of numbers under the screen, kind of like those same GPS coordinates. The dimension and the algorithm that you use to generate that vector can be different across different databases, but the actual meaning of that data will change. And so GoldenGate can replicate the vector data as long as the algorithm and the dimensions are the same. If the algorithm and the dimensions are not the same between the source and the target, then you'll actually want GoldenGate to replicate the base data that created that vector. And then once GoldenGate replicates the base data, it'll actually call the vector embedding technology to re-embed that data and produce that numerical formatting for you.  15:42 Lois: So, there are some nuances there… Nick: GoldenGate can also replicate and consolidate vector changes or even do the embedding API calls itself. This is really nice because it means that we can take changes from multiple systems and consolidate them into a single one. We can also do the reverse of that too. A lot of customers are still trying to find out which algorithms work best for them. How many dimensions? What's the optimal use? Well, you can now run those in different servers without impacting your actual AI system. Once you've identified which algorithm and dimension is going to be best for your data, you can then have GoldenGate replicate that into your production system and we'll start using that instead. So it's a nice way to switch algorithms without taking extensive downtime. 16:29 Nikita: What about in multicloud environments?  Nick: GoldenGate can also do multicloud and N-way active-active Oracle replication between vectors. So if there's vectors in Oracle databases, in multiple clouds, or multiple on-premise databases, GoldenGate can synchronize them all up. And of course we can also stream changes from vector information, including text as well into different search engines. And that's where the integration with Elasticsearch and OpenSearch comes in. And then we can use things like NVIDIA and Cohere to actually do the AI on that data.  17:01 Lois: Using GoldenGate with AI in the database unlocks so many possibilities. Thanks for that detailed introduction to Oracle GoldenGate 23ai and its capabilities, Nick.  Nikita: We've run out of time for today, but Nick will be back next week to talk about how GoldenGate has evolved over time and its latest features. And if you liked what you heard today, head over to mylearn.oracle.com and take a look at the Oracle GoldenGate 23ai Fundamentals course to learn more. Until next time, this is Nikita Abraham… Lois: And Lois Houston, signing off! 17:33 That's all for this episode of the Oracle University Podcast. If you enjoyed listening, please click Subscribe to get all the latest episodes. We'd also love it if you would take a moment to rate and review us on your podcast app. See you again on the next episode of the Oracle University Podcast.

Patrick Lencioni is the co-founder and President of The Table Group and is the pioneer of the organizational health movement. He is the author of 13 books, including The Five Dysfunctions of A Team, The Five Temptations of a CEO and The Motive. His books have sold over 8 million copies and been translated into more than 30 languages. As President of the Table Group, Pat spends his time speaking and writing about leadership, teamwork, and organizational health and consulting with executives and their teams. Prior to founding the firm in 1997, Pat worked at Bain & Company, Oracle Corporation and Sybase.  On this classic episode, Pat joined host Robert Glazer on the Elevate Podcast to talk about his leadership journey, how he developed the organizational health movement, keys to effective and ineffective leadership and cultures, and much more. Learn more about your ad choices. Visit megaphone.fm/adchoices

Stephen Plume has more than 20 years of success in venture, executive leadership, and consulting. He is a General Partner of an early-stage venture fund since 2019, driving business strategy and coaching executives in the portfolio. In this episode, Stephen discusses how AI is shifting pricing models from human-based to consumption-based metrics. He emphasizes the importance of identifying the right value metric that resonates with customers encouraging businesses to experiment with pricing to uncover hidden revenue and margin opportunities.   Why you have to check out today's podcast: Gain insights into the cutting-edge pricing strategies for AI companies and how these differ from traditional user-based models to get a glimpse of the future of tech pricing. Learn about actionable strategies like identifying the right value metric and conducting low-risk pricing experiments, which can help businesses capture hidden revenue and improve margins. Deep dive into how venture capitalists think about returns, risk, and value, which can benefit entrepreneurs and business owners seeking to understand how to attract investment.   "There is so much opportunity to learn from low-risk pricing experiments, and people worry so much about their reputation. Get over that feeling, go out and experiment, and learn from it." - Stephen Plume   Topics Covered: 01:54 - A funny thing about Stephen not related to pricing 02:46 - How he found his way into pricing 04:21 - Reflecting on his first pricing project with Sybase 05:57 - Contrasting enterprise-level pricing with startup pricing, highlighting the complexity of pricing for larger companies  09:12 - The importance of focusing on the Ideal Customer Profile (ICP) for early-stage companies 10:39 - Explaining how companies often face pricing erosion as they grow and introducing the concept of 'layering' and 'fencing' 16:38 - Discussing how companies, like HubSpot and Salesforce, often start by solving a specific problem with a focused solution but later expand by adding numerous features and add-ons 17:27 - Delving into the concept of competitive positioning 21:40 - The importance of delivering significant value to customers to motivate a decision to switch from a competitor or the status quo 25:09 - Sharing insights about pricing for AI companies and broader trends in AI adoption 29:14 - Discussing the concept of pricing metrics in the context of AI and SaaS 30:32 - Stephen's best pricing advice   Key Takeaways: "When I'm working with early stage companies my drumbeat is, don't worry about anybody else right now, worry about your ideal customer profile. Because they are the ones who, by definition because math is a thing, will pay you more money faster than anyone else." - Stephen Plume "In the venture world what I tell the early companies I work with is, for someone to take a bet on you, they're expecting venture returns. They need to be getting 10X their money out. That's not just the investors. That's the customers need to be getting 10X their cost out, or they're not going to adopt you." - Stephen Plume "The advantage of a platform growing to solutions is, if you do it right, your margins improve rather dramatically." - Stephen Plume   People/Resources Mentioned: Sybase: https://en.wikipedia.org/wiki/Sybase Salesforce: https://www.salesforce.com/ap/?ir=1 Cisco: https://www.cisco.com/#tabs-35d568e0ff-item-194f491212-tab Regis McKenna: https://en.wikipedia.org/wiki/Regis_McKenna Geoffrey Moore: http://geoffreyamoore.com Steve Blank: https://steveblank.com HubSpot: https://www.hubspot.com Zoom: https://zoom.us LinkedIn: https://www.linkedin.com Siebel: https://www.oracle.com/ph/cx/siebel/ Zendesk: https://www.zendesk.com Intercom: https://www.intercom.com Clayton Christensen: https://en.wikipedia.org/wiki/Clayton_Christensen   Connect with Stephen Plume: LinkedIn: https://www.linkedin.com/in/stephenplume/   Connect with Mark Stiving: LinkedIn: https://www.linkedin.com/in/stiving/ Email: mark@impactpricing.com  

We had a blast at ELC Annual 2024, so we wanted to bring our podcast listeners some of the best highlights from popular sessions! This episode features one of the ELC Annual sessions with Anupam Singh (VP of AI & Growth Engineering @ Roblox) & Maria Kazandjieva (Co-Founder @ Graft), as they discuss building AI/ML models at a massive scale. Anupam shares how Roblox – an immersive 3D platform with more than 77 million daily active users – scaled from zero to nearly 200 different AI models. They discuss strategies for deciding when to use open source vs. creating proprietary models; how to operationalize your models for 24/7 use; the importance of data pipelines; current and future challenges to keep in mind when creating / scaling AI models; and answer some questions from the live Q&A.ABOUT ANUPAM SINGHAnupam leads Roblox's AI & Growth engineering teams, which provide the infrastructure for high throughput AI services for safety, recommendations, and assistants. Before Roblox, Anupam was chief customer officer at Cloudera, where he led product, engineering, and field teams for Data Warehousing products. Anupam has co-founded two companies in the Big Data space, acquired by Cloudera and Marketshare, respectively. Anupam built his database expertise on the SQL Query Optimizer teams at Oracle, Sybase (now SAP), and Informix (now IBM). He graduated from Pune University in India and holds patents in the areas of automatic SQL performance tuning, object databases, and resilient query execution."The journey always starts with, 'Let's pick a model and first decide whether we want to build our own model or we want to use one of the open source ones.' The next step is, 'Do you want to do it on public cloud?' Roblox has 24 data centers worldwide and two massive data centers in America. We have hundreds of thousands of CPUs that we could use and so for us, it's very important to decide, 'Do we really need a large model? Can you take the 700 billion model, make it into a 7 billion parameter model, and magically get it to run on the CPU?'”- Anupam Singh   ABOUT MARIA KAZANDJIEVAMaria is a co-founder and an engineering leader at Graft, an early-stage AI startup. Prior to that, Maria worked at Netflix, where her team earned two Emmy awards for technical achievement. She holds a PhD in Computer Science from Stanford University. Outside of work, you can find Maria kickboxing & trail running, baking & eating carbs, or relaxing with a non-fiction book and her two feline supurrvisors, Foosball and Gemma.SHOW NOTES:How Roblox is being powered by AI (00:30)The process of scaling AI models from zero to 200 @ Roblox (2:34)Examples of Roblox starting with open source vs. building its own model (5:06)What AI models are doing in terms of safety for children (7:12)Strategies for deciding to use open source vs. building a proprietary model (11:19)Why Roblox is choosing to open source some of their own models (13:06)How to operationalize / engineer AI models for 24/7 use at scale (14:20)The importance of data pipelines in the AI journey (16:18)Current / future challenges as Roblox continues to scale its models (19:52)Tips for identifying use cases where implementing & scaling AI can be helpful (22:21)Audience Q&A: How do you make decisions when you're lacking specific measurements / quantities? (24:29)When you deploy a model, how do you ensure confidence in its performance? (27:36)Recommendations for allocating / estimating the budget for a model (29:03)Anupam's insights on maintaining so many models effectively (31:03)How do you imagine the multimodality of your 3D models moving forward? (33:11)This episode wouldn't have been possible without the help of our incredible production team:Patrick Gallagher - Producer & Co-HostJerry Li - Co-HostNoah Olberding - Associate Producer, Audio & Video Editor https://www.linkedin.com/in/noah-olberding/Dan Overheim - Audio Engineer, Dan's also an avid 3D printer - https://www.bnd3d.com/Ellie Coggins Angus - Copywriter, Check out her other work at https://elliecoggins.com/about/

Patrick Lencioni is co-founder and President of The Table Group and is the pioneer of the organizational health movement. He is the author of 13 books, which have sold over 8 million copies and been translated into more than 30 languages. As President of the Table Group, Pat spends his time speaking and writing about leadership, teamwork, and organizational health and consulting with executives and their teams. Prior to founding the firm in 1997, Pat worked at Bain & Company, Oracle Corporation and Sybase. In his second appearance on the Elevate Podcast, Patrick returned to the show to discuss the role company leaders should play in sociopolitical issues, how to set proper expectations with employees and customers about where a company stands on social issues, and why leaning on values is as crucial as ever in leadership today. Learn more about your ad choices. Visit megaphone.fm/adchoices

E106 Fireside with a VC speaking with Ken Goldman, former President of Eric & Wendy Schmidt's family office, former CFO of Yahoo!, Fortinet, Siebel Systems (acquired by Oracle), Excite@Home, Sybase, and Cypress Semiconductor. Discussed the changes in VC, going public and the reasons companies should go public again, the problems secondaries for founders create, how to leave a company ethically, general advice on how to win in the big leagues, selling Siebel to Oracle, the dynamics of changing CEOs, lessons learned from board of directors dynamics at Yahoo!, working with activist shareholders, how enterprise software companies should or should not go international, running Eric and Wendy Schmidt's family office, and now speaking at family office and other conferences. Find the full episode on YouTube: https://youtu.be/krSWnl3eGco. Find this and all full episodes for Fireside with a VC on your favorite podcast platform here: https://podcasters.spotify.com/pod/show/FiresideVC. https://www.7bc.vc/ https://www.linkedin.com/in/romans/ Join our Newsletter to get our insights and favorite curated content from the VC-startup ecosystem - Fireside with a VC: https://subscribe.7bc.vc. Join the conversation, leave comments, and tell us what you think about these topics and this episode. --- Send in a voice message: https://podcasters.spotify.com/pod/show/firesidevc/message

  Are you ready to explore the future of data and AI? In our upcoming episode of Tech Talks Daily, I am thrilled to welcome Irfan Khan, Chief Product Officer at SAP, to discuss SAP's groundbreaking data and analytics portfolio, particularly the new SAP Data Sphere offering. Irfan brings a wealth of experience and insights, starting from his early interest in technology inspired by his father to his formative computing experiences with the BBC Micro and Amstrad CPC 464. His journey from CTO at Sybase to various sales roles at SAP has given him a unique customer-centric perspective that fuels his innovative approach to data and AI. Our conversation dives deep into the SAP Data Sphere, a revolutionary business virtual data fabric concept that allows for data federation without the need for physical data consolidation. This groundbreaking approach preserves data context and metadata, which are critical for training high-quality generative AI models. Irfan explains how Data Sphere leverages knowledge graphs and vector stores to enable contextual AI capabilities, allowing businesses to detect signals and patterns across disparate data sources for applications like supply chain optimization. One of the standout aspects of our discussion is the emphasis on data quality, lineage, and ethical use, which are paramount for the responsible deployment of generative AI. Irfan shares SAP's commitment to ethical AI, including the formation of an ethical AI committee to vet models before production use, and discusses the measures taken to prevent hallucinations, cultural biases, and maintain data integrity. Irfan also highlights real-world applications of SAP Data Sphere and generative AI, such as detecting early signals of supply chain disruptions and ethically screening candidates for recruitment. These examples showcase how generative AI is enhancing business applications across various industries, driving innovation, and supporting better decision-making. Looking ahead, Irfan paints an exciting picture of the future of data and AI, with rapid innovation from big tech players like Google, Meta, and OpenAI. He underscores the importance of continuous learning through bite-sized content and networking to stay ahead in this dynamic field. What steps can your business take to leverage the power of AI and contextual data? Tune in to this episode to gain valuable insights from Irfan Khan and discover how SAP's innovative solutions can transform your data management and AI strategies. After listening, I'd love to hear your thoughts on the role of generative AI in your business and how you plan to practice better data hygiene for responsible AI use.

In episode 195 of our SAP on Azure video podcast we talk about backup. Already in previous episodes we had talked about Backup as one of the interaction points of the Azure Center for SAP Solutions. Today Pradeep and Tunde provide more details on how Azure Backup for SAP works, what features are available and how customers can use this service. Azure Backup for SAP is not only available for SAP HAHA and SQL Service, but also Sybase. Find all the links mentioned here: https://www.saponazurepodcast.de/episode195 Reach out to us for any feedback / questions: * Robert Boban: https://www.linkedin.com/in/rboban/ * Goran Condric: https://www.linkedin.com/in/gorancondric/ * Holger Bruchelt: https://www.linkedin.com/in/holger-bruchelt/ #Microsoft #SAP #Azure #SAPonAzure #Backup

Alan interviews Pat Lencioni for part 2 of our Working Genius series. This episode focuses on how to apply The Working Genius to teams. This is THE best assessment we've ever seen for team alignment and common language. We are honored to have The Working Genius as a sponsor for this podcast. Go take the assessment at www.WorkingGenius.com. If you would like Alan to lead a training to translate this assessment into your tea, email us at hello@stayforth.com About Pat Lencioni Pat is one of the founders of The Table Group and is the pioneer of the organizational health movement. He is the author of 13 books, which have sold over 8 million copies and been translated into more than 30 languages. As President of the Table Group, Pat spends his time speaking and writing about leadership, teamwork, and organizational health and consulting with executives and their teams. Prior to founding the firm in 1997, Pat worked at Bain & Company, Oracle Corporation and Sybase. Pat lives in the Bay Area with his wife and four boys. Takeaways Understanding the six types of working genius can transform teams and improve productivity and morale. Borrowing geniuses across teams can lead to increased innovation and success. Understanding frustrations can be liberating and prevent burnout. The team map is a valuable tool for visualizing the distribution of geniuses and frustrations within a team. Using the vocabulary of working genius can improve team communication and project flow. Understanding individual and team dynamics is crucial for improving productivity and avoiding conflict. The concept of working genius identifies six types of genius that individuals possess. Clarity and communication are essential for ensuring alignment within teams. Working genius can be connected to other concepts introduced by Lencioni, such as the five dysfunctions of a team and the ideal team player. Taking the working genius assessment can provide valuable insights for individuals and teams. Quotables "Nobody on their team had the genius of wonder." "Let's just put people in the right role and give them the right responsibilities that correspond to what gives them joy and energy." "She has enablement, which means whenever a customer or an employee says, I need help, she's right there." "You have to see how it comes about. And we know it's going to be painful for you." "People can now actually call each other out on things in a way that doesn't feel like they're being judged or attacked, but they're being honored." "People talk to one another using the language of working genius, which in a good way objectifies feedback that used to feel personal."  

On this episode, Alan Interviews legendary author and organizational consultant Pat Lencioni about The Working Genius assessment and message. We are honored to have The Working Genius as a sponsor for this podcast. In this episode which is a two part mini series, we delve into what The Working Genius is and how to understand the framework. Go take the assessment at WorkingGenius.com. If you would like Alan to lead a team training to incorporate this assessment into your team you can get more information by emailing us at hello@stayforth.com  About Pat Lencioni Pat is one of the founders of The Table Group and is the pioneer of the organizational health movement. He is the author of 13 books, which have sold over 8 million copies and been translated into more than 30 languages. As President of the Table Group, Pat spends his time speaking and writing about leadership, teamwork, and organizational health and consulting with executives and their teams. Prior to founding the firm in 1997, Pat worked at Bain & Company, Oracle Corporation and Sybase. Pat lives in the Bay Area with his wife and four boys.  Takeaways Organizational health is important for avoiding burnout and creating healthy cultures. The six types of working genius are wonder, invention, discernment, galvanizing, enablement, and tenacity. Wonderers ask questions and ponder new ideas, while inventors come up with new ideas and solutions. Discerners evaluate ideas and have great pattern recognition instinct. Galvanizers rally the troops and inspire others, while enablers answer the call for help and support. Tenacious individuals plow through obstacles and finish tasks. Both disruptive and responsive geniuses are needed in a team. IGs (Invention and Galvanizing) are naturally excited about new ideas and enjoy sharing them. IDs (Invention and Discernment) evaluate and edit ideas as they come up with them. Understanding and celebrating each other's geniuses can lead to a more productive and joyful team. An ideal day for an ID might involve coming up with new ideas and having coaching conversations. An ideal day for an IG might involve launching new ideas and getting people excited about them.

  April Dunford is the founder of Ambient Strategy, a consulting firm that helps technology companies grow. She has led marketing, product, and sales teams at companies like IBM, Siebel, and Sybase. April's work is focused on early and growth-stage startups—recognizing that weak positioning can be the difference between success and failure. She also works with large global companies, helping them develop deeper positioning expertise in their product and marketing teams. April's best-selling book, Obviously Awesome, captures her ideas about positioning and provides a methodology that any startup can follow. Today, April is focused on giving back as much as she can. She mentors and advises dozens of startups and is an enthusiastic board member at a handful of startups. April resides in Toronto, Canada, where she enjoys spending time with her kids and small dog in a cabin in the woods.   Today, April joins me to discuss positioning for B2B tech companies. She explains how to position a product to the current market, rather than the company's vision of the future. She discusses what product managers need to understand about their vision and the current market to craft a successful position. She explains why product positioning is most important in B2B and why positioning is different from messaging. We discuss the importance of positioning to improve marketing and sales performance and why you need to continually refine and evolve positioning over time. April also suggests the best way to develop a positioning thesis and calculate the value it will deliver to the customer.   “The best way to test positioning if you're B2B and you have a sales team is to take that positioning and translate it into a sales pitch, then test it out on qualified prospects in a sales call.” - April Dunford   This week on Innovation Talks:   ●     How to explore the best positioning strategy for your company ●     How B2B tech companies can position themselves for their specific market ●     Why weak positioning makes your sales process harder ●     April's five components of positioning ●     April's methodology for positioning that any company can follow ●     How to test your positioning ●     The benefits of structured sales pitches   Connect with April Dunford:   ●     April Dunford's Website (https://www.aprildunford.com/) ●     Book: Obviously Awesome: How to Nail Product Positioning so Customers Get It, Buy It, Love It by April Dunford (https://www.amazon.com/Obviously-Awesome-Product-Positioning-Customers/dp/1999023005/) ●     April Dunford on LinkedIn (https://www.linkedin.com/in/aprildunford/) ●     April Dunford on Twitter (https://twitter.com/aprildunford)   This Podcast is brought to you by Sopheon   Thanks for tuning into this week's episode of Innovation Talks. If you enjoyed this episode, please subscribe and leave a review wherever you get your podcasts.   Apple Podcasts (https://podcasts.apple.com/us/podcast/innovation-talks/id1555857396) | TuneIn (https://tunein.com/podcasts/Technology-Podcasts/Innovation-Talks-p1412337/) | GooglePlay (https://www.google.com/podcasts?feed=aHR0cHM6Ly9pbm5vdmF0aW9udGFsa3MubGlic3luLmNvbS9yc3M%3D) | Stitcher (https://www.stitcher.com/s?fid=614195) | Spotify (https://open.spotify.com/show/1dX5b8tWI29YbgeMwZF5Uh) | iHeart (https://www.iheart.com/podcast/263-innovation-talks-82985745/)   Be sure to connect with us on Facebook (https://www.facebook.com/SopheonCorp/) , Twitter (https://twitter.com/sopheon) , and LinkedIn (https://www.linkedin.com/company/sopheon/) , and share your favorite episodes on social media to help us reach more listeners, like you.   For additional information around new product development or corporate innovation, sign up for Sopheon's newsletter where we share news and industry best practices monthly! The fastest way to do this is to go to sopheon.com (https://www.sopheon.com/) and click here (https://info.sopheon.com/subscribe) .  

  April Dunford is the founder of Ambient Strategy, a consulting firm that helps technology companies grow. She has led marketing, product, and sales teams at companies like IBM, Siebel, and Sybase. April's work is focused on early and growth-stage startups—recognizing that weak positioning can be the difference between success and failure. She also works with large global companies, helping them develop deeper positioning expertise in their product and marketing teams. April's best-selling book, Obviously Awesome, captures her ideas about positioning and provides a methodology that any startup can follow. Today, April is focused on giving back as much as she can. She mentors and advises dozens of startups and is an enthusiastic board member at a handful of startups. April resides in Toronto, Canada, where she enjoys spending time with her kids and small dog in a cabin in the woods.   Today, April joins me to discuss positioning for B2B tech companies. She explains how to position a product to the current market, rather than the company's vision of the future. She discusses what product managers need to understand about their vision and the current market to craft a successful position. She explains why product positioning is most important in B2B and why positioning is different from messaging. We discuss the importance of positioning to improve marketing and sales performance and why you need to continually refine and evolve positioning over time. April also suggests the best way to develop a positioning thesis and calculate the value it will deliver to the customer.   “The best way to test positioning if you're B2B and you have a sales team is to take that positioning and translate it into a sales pitch, then test it out on qualified prospects in a sales call.” - April Dunford   This week on Innovation Talks:   ●     How to explore the best positioning strategy for your company ●     How B2B tech companies can position themselves for their specific market ●     Why weak positioning makes your sales process harder ●     April's five components of positioning ●     April's methodology for positioning that any company can follow ●     How to test your positioning ●     The benefits of structured sales pitches   Connect with April Dunford:   ●     April Dunford's Website (https://www.aprildunford.com/) ●     Book: Obviously Awesome: How to Nail Product Positioning so Customers Get It, Buy It, Love It by April Dunford (https://www.amazon.com/Obviously-Awesome-Product-Positioning-Customers/dp/1999023005/) ●     April Dunford on LinkedIn (https://www.linkedin.com/in/aprildunford/) ●     April Dunford on Twitter (https://twitter.com/aprildunford)   This Podcast is brought to you by Sopheon   Thanks for tuning into this week's episode of Innovation Talks. If you enjoyed this episode, please subscribe and leave a review wherever you get your podcasts.   Apple Podcasts (https://podcasts.apple.com/us/podcast/innovation-talks/id1555857396) | TuneIn (https://tunein.com/podcasts/Technology-Podcasts/Innovation-Talks-p1412337/) | GooglePlay (https://www.google.com/podcasts?feed=aHR0cHM6Ly9pbm5vdmF0aW9udGFsa3MubGlic3luLmNvbS9yc3M%3D) | Stitcher (https://www.stitcher.com/s?fid=614195) | Spotify (https://open.spotify.com/show/1dX5b8tWI29YbgeMwZF5Uh) | iHeart (https://www.iheart.com/podcast/263-innovation-talks-82985745/)   Be sure to connect with us on Facebook (https://www.facebook.com/SopheonCorp/) , Twitter (https://twitter.com/sopheon) , and LinkedIn (https://www.linkedin.com/company/sopheon/) , and share your favorite episodes on social media to help us reach more listeners, like you.   For additional information around new product development or corporate innovation, sign up for Sopheon's newsletter where we share news and industry best practices monthly! The fastest way to do this is to go to sopheon.com (https://www.sopheon.com/) and click here (https://info.sopheon.com/subscribe) .

 April Dunford is the founder of Ambient Strategy, a consulting firm that helps technology companies grow. She has led marketing, product, and sales teams at companies like IBM, Siebel, and Sybase. April's work is focused on early and growth-stage startups—recognizing that weak positioning can be the difference between success and failure. She also works with large global companies, helping them develop deeper positioning expertise in their product and marketing teams. April's best-selling book, Obviously Awesome, captures her ideas about positioning and provides a methodology that any startup can follow. Today, April is focused on giving back as much as she can. She mentors and advises dozens of startups and is an enthusiastic board member at a handful of startups. April resides in Toronto, Canada, where she enjoys spending time with her kids and small dog in a cabin in the woods. Today, April joins me to discuss positioning for B2B tech companies. She explains how to position a product to the current market, rather than the company's vision of the future. She discusses what product managers need to understand about their vision and the current market to craft a successful position. She explains why product positioning is most important in B2B and why positioning is different from messaging. We discuss the importance of positioning to improve marketing and sales performance and why you need to continually refine and evolve positioning over time. April also suggests the best way to develop a positioning thesis and calculate the value it will deliver to the customer. “The best way to test positioning if you're B2B and you have a sales team is to take that positioning and translate it into a sales pitch, then test it out on qualified prospects in a sales call.” - April Dunford This week on Innovation Talks: ●     How to explore the best positioning strategy for your company ●     How B2B tech companies can position themselves for their specific market ●     Why weak positioning makes your sales process harder ●     April's five components of positioning ●     April's methodology for positioning that any company can follow●     How to test your positioning ●     The benefits of structured sales pitches  Connect with April Dunford: ●     April Dunford's Website●     Book: Obviously Awesome: How to Nail Product Positioning so Customers Get It, Buy It, Love It by April Dunford●     April Dunford on LinkedIn●     April Dunford on Twitter This Podcast is brought to you by Sopheon Thanks for tuning into this week's episode of Innovation Talks. If you enjoyed this episode, please subscribe and leave a review wherever you get your podcasts. Apple Podcasts | TuneIn | GooglePlay | Stitcher | Spotify | iHeart Be sure to connect with us on Facebook, Twitter, and LinkedIn, and share your favorite episodes on social media to help us reach more listeners, like you. For additional information around new product development or corporate innovation, sign up for Sopheon's newsletter where we share news and industry best practices monthly! The fastest way to do this is to go to sopheon.com and click here.

Navigating the tech world easily, John O'Connell transformed himself from a Programmer to an Entrepreneur and masterfully led a company to its first IPO. Today, As the CEO and Founder of The Oasis Group, John spearheads growth, guiding firms in wealth management, fintech, and financial services to transcend limits and rejuvenate their growth trajectories.In this not-to-be-missed episode, recorded live from Schwab IMPACT, John and I delve deep into the mind of a visionary who's not just leading the charge but rewriting the playbook of technological evolution. John's odyssey is nothing short of legendary from his early days of coding wizardry to architecting the future of data management with industry behemoths like Sybase and Oracle. As a vanguard in the database revolution, he's sculpted the landscape of customer relations and data management, turning complex challenges into groundbreaking triumphs.But hold onto your seats because John's saga doesn't stop there. In 2019, John founded The Oasis Group, and as CEO today, steering asset managers, independent broker-dealers, and registered investment advisors through the digital transformation of the 21st century. John was named to the  InvestmentNews Hot List last year and his work was featured in the T3 Technology Tools for Today T3 2024 Conference stage along with Joel Bruckenstien and Survey. So, plug in, ignite your curiosity, and prepare to be captivated by a tech entrepreneur who's not just walking the tech talk but is blazing a trail for the digital titans of tomorrow. Our conversation with John will help redefine your perspective on technology and leadership in the suite. Links - John O'Connell - LinkedIn - The Oasis Group - Website - "Rise of The Activist Investor" - Amazon Page - T3 Technology Tools for Today 2023 Survey - Link to Survey

Robert Hodges is CEO of Altinity, which helps enterprises build real-time analytics using ClickHouse. He has been working on databases as well as the applications that use them since the early 1980s. The journey included Sybase and Oracle in the 1990s, MySQL and PostgreSQL in the early 2000s, followed by analytic databases starting in 2010. Robert's technical interests include distributed systems, open source software, and Kubernetes. He is stoked to be part of the next wave of technology based on open source analytic databases. It's a privilege to help users discover creative new uses for data and technology!

John Care spent numerous years building world-class Sales Engineering organizations at Oracle, Sybase, Vantive, Clarify, CA, Business Objects, and HP Software. He has a BSc with Honours in Chemical Engineering from Imperial College, London, and is a former contributing member of the MBA Advisory Council for the Fox Business School of Temple University, Philadelphia. He has been published in such diverse media as CIO, InfoWorld, Touchline, and The Wall Street Journal. He now serves on the Advisory Boards of several hi-tech startups dedicated to the Sales Engineering community.In this episode, John Care, co-author of "Mastering Technical Sales," joins hosts John McMahon and John Kaplan to discuss the role of technical sales and how sales leaders can effectively utilize sales engineers (SEs) to demonstrate customer value and differentiate their solutions. They emphasize the importance of building relationships, storytelling, and slowing down to go fast in the sales process. The conversation also covers the partnership between SEs and account executives (AEs), the value SEs bring to the sales team, and the significance of qualification and preparation before demos and proof of concepts (POCs)Tune in to this conversation with John McMahon and John Kaplan on the Revenue Builders podcast.HERE ARE SOME KEY SECTIONS TO CHECK OUT[00:03:19] Discussion on what makes a good SE[00:05:49] Data on the value provided by SEs[00:07:01] Importance of storytelling for SEs[00:11:08] The attribute of patience in SEs[00:20:30] Sales engineers should be seen as partners in the sales cycle[00:23:55] Constant communication with the sales engineer is key for success[00:28:55] The importance of debriefing after sales calls[00:35:38] The pros and cons of dashing to the demo[00:42:03] The importance of qualification before a demo[00:54:01] The role of SEs in post-sales and consumption-based modelsADDITIONAL RESOURCESLearn more about John Care and their company.john@masteringtechnicalsales.comhttps://www.linkedin.com/in/johncare/https://www.linkedin.com/company/up-2-speed/Download our Sales Transformation Guide for Leaders:https://forc.mx/3sdtEZJHIGHLIGHT QUOTES[00:57:19] "The SE knows more people, that knows where the bodies are buried, as we like to say, and can actually be the guide for, a new rep as they come in or a new strategy."[01:01:26] "If you're an SE who wants to go over into sales, normally it's better if you go over either into an overlay position or into a pharma type position, as opposed to, hunter killers, new logos type accounts."

Have you ever wondered why, despite having amazing products, customers still struggle to understand your company's value?April Dunford, an authority on product positioning, discusses the critical role of positioning in sales and marketing. Known for her first book "Obviously Awesome" and her expertise in positioning, April shares her insights on why companies often struggle with positioning their products. She emphasizes that most companies have positioning, but it's not deliberate, leading to misalignment and missed opportunities. April highlights the transformative power of effective positioning, using an illustrative story from her early career where repositioning a product from enterprise CRM to CRM for investment banks led to significant business growth and acquisition by a major player.The episode underscores the common disconnect between how companies perceive their products and how customers understand them. April points out the importance of involving sales teams in positioning discussions, as they have direct insights into customer perceptions and competitors. And describes in her second book, Sales Pitch, how to translate the marketing work done for positioning into sales speak. April advises CEOs to routinely reassess their company's positioning, even if it seems satisfactory, to ensure alignment with market realities. She stresses the need for a cross-functional team approach to redefine positioning involving sales, marketing, and product teams. The episode serves as a crucial reminder for CEOs and sales leaders of the importance of clear and strategic positioning in today's competitive market. April Dunford's insights offer valuable guidance on how to approach this process thoughtfully and effectively to drive business growth and customer satisfaction.This podcast is a must listen and her books are both must reads. Chapters05:26 Lack of methodology and squishiness surrounding positioning in marketing0:09:02 Naming of April Dunford's books: "Obviously Awesome" and "Sales Pitch"11:12 Importance of aligning positioning with customer perception14:01 Components of positioning: competition, differentiation, value, customer, market19:07 Example of a company positioned as Enterprise CRM but found success in investment banking22:36 Shifting positioning to target specific industries led to success25:51 Understanding the buyer's perspective and guiding them through the buying process31:20 Buyers are overwhelmed with information and struggle to make decisions33:56 Poor positioning and difficult buying process on websites.39:07 Cross functional team approach to positioning.42:45 Leveraging product knowledge to identify unique value propositions.44:59 Characteristics of a Best Fit customer and market categories46:13 Mapping positioning to a sales narrative for effective storytellingSocial Links You can learn more about and connect with April Dunford in the links below.Connect with April on LinkedIn:(99+) April Dunford | LinkedInCheck out April's website:April Dunford - Positioning for B2B Tech CompaniesCheck out April's Podcast:Positioning With April DunfordCheck out April's NewsletterPositioning with April Dunford | SubstackYou can learn more about and connect with Alice Heiman in the links below.Connect with Alice on LinkedIn:(99+) Alice Heiman | LinkedInCheck out Alice's website:Alice Heiman - Alice HeimanAbout GuestI spent the first 25 years of my career as a startup executive, running marketing, product, and sales teams. I led teams at seven successful B2B technology startups. Most of those startups were acquired (DataMirror to IBM, Janna Systems to Siebel Systems, then SAP, Watcom to Sybase via Powersoft, to name a few), and I ran big teams at IBM, Siebel, Sybase, and others. The total of those acquisitions is more than two billion dollars. Across that journey, I positioned, re-positioned, and launched 16 products, and created dozens of sales pitches.I have a deep curiosity about what makes the difference between a winning product and a loser. Developing a systematic way of positioning technology products and companies has become my life's work. As a consultant, I have had the privilege of working with more than 200 companies, allowing me to go even deeper and broaden my positioning expertise. The bulk of my work is with growth-stage startups and larger technology companies. Companies where the stakes are high - and weak positioning can mean the difference between success or failure.My first book, Obviously Awesome - How to Nail Product Positioning so Customers Get it, Buy it, Love it (aprildunford.com), captures my ideas about positioning and a methodology for doing it that any startup can follow. It's become a best-seller and popular among entrepreneurs, product, and marketing folk. My second book, Sales Pitch, was designed to teach a step-by-step way of building a sales pitch that reflects that positioning, and helps make a clear compelling case for why prospects should pick you over the competition.I studied Engineering at the University of Waterloo. If you had told me back then that someday I would be an author, I would have said you were nuts. It turns out my grade 6 English teacher was wrong about the importance of grammar. I'm at the stage of my career where I'm trying to give back as much as I can. I am a mentor and advisor to dozens of startups and folks that work in them. I am also an enthusiastic board member at a handful of startups. I live in Toronto, Canada. I have kids, a small dog, and a cabin in the woods.

Patrick Lencioni is the co-founder and President of The Table Group and is the pioneer of the organizational health movement. He is the author of 13 books, including The Five Dysfunctions of A Team, The Five Temptations of a CEO and The Motive. His books have sold over 8 million copies and been translated into more than 30 languages. As President of the Table Group, Pat spends his time speaking and writing about leadership, teamwork, and organizational health and consulting with executives and their teams. Prior to founding the firm in 1997, Pat worked at Bain & Company, Oracle Corporation and Sybase.  Pat joined host Robert Glazer on the Elevate Podcast to talk about his leadership journey, how he developed the organizational health movement, keys to effective and ineffective leadership and cultures, and much more. Learn more about your ad choices. Visit megaphone.fm/adchoices

Special Guest: Josh Bersin: CEO of The Josh Bersin Company HR influencer Josh Bersin, CEO of workplace trends research firm The Josh Bersin Company, believes it is time capitalism got back to helping individuals build rewarding careers. Now, he wants to talk how. Josh has published widely on this topic, in particular in his just-published book, Irresistible, which surfaces the seven secrets of the most enduring employee-focused organisations. On this show, Josh will discuss the management values organisations need to adopt to become irresistible in their chosen markets, practical strategies that embrace the power of every individual and leverage the speed, technologies and the flexible work arrangements we need to engage with to finally confront the social and cultural issues of our time. Josh is the founder of Bersin & Associates (now Bersin by Deloitte), the Josh Bersin Academy, the professional development platform, and The Josh Bersin Company, an independent research firm which provides research and advisory services to global corporations covering all areas of HR, learning, and HR technology. He is a columnist for the Sloan Management Review, a leading LinkedIn influencer, and has been a regular op-ed writer for HR Executive magazine. Josh spent 25 years in product development, product management, marketing and sales of e-learning and other enterprise technologies at companies including DigitalThink (now Convergys), Arista Knowledge Systems, Sybase, and IBM. Josh's education includes a B.S. in Engineering from Cornell University, an M.S. in the same discipline from Stanford University, and an MBA from the Haas School of Business at the University of California. Join us as we discuss the management values organisations need to adopt to become irresistible. Listen Live (Archive Available) Host: Jo Moffatt

 April Dunford is the founder of Ambient Strategy, a consulting firm that helps technology companies grow. She has led marketing, product, and sales teams at companies like IBM, Siebel, and Sybase. April's work is focused on early and growth-stage startups—recognizing that weak positioning can be the difference between success and failure. She also works with large global companies, helping them develop deeper positioning expertise in their product and marketing teams. April's best-selling book, Obviously Awesome, captures her ideas about positioning and provides a methodology that any startup can follow. Today, April is focused on giving back as much as she can. She mentors and advises dozens of startups and is an enthusiastic board member at a handful of startups. April resides in Toronto, Canada, where she enjoys spending time with her kids and small dog in a cabin in the woods. Today, April joins me to discuss positioning for B2B tech companies. She explains how to position a product to the current market, rather than the company's vision of the future. She discusses what product managers need to understand about their vision and the current market to craft a successful position. She explains why product positioning is most important in B2B and why positioning is different from messaging. We discuss the importance of positioning to improve marketing and sales performance and why you need to continually refine and evolve positioning over time. April also suggests the best way to develop a positioning thesis and calculate the value it will deliver to the customer. “The best way to test positioning if you're B2B and you have a sales team is to take that positioning and translate it into a sales pitch, then test it out on qualified prospects in a sales call.” - April Dunford This week on Innovation Talks: ●     How to explore the best positioning strategy for your company ●     How B2B tech companies can position themselves for their specific market ●     Why weak positioning makes your sales process harder ●     April's five components of positioning ●     April's methodology for positioning that any company can follow●     How to test your positioning ●     The benefits of structured sales pitches  Connect with April Dunford: ●     April Dunford's Website●     Book: Obviously Awesome: How to Nail Product Positioning so Customers Get It, Buy It, Love It by April Dunford●     April Dunford on LinkedIn●     April Dunford on Twitter This Podcast is brought to you by Sopheon Thanks for tuning into this week's episode of Innovation Talks. If you enjoyed this episode, please subscribe and leave a review wherever you get your podcasts. Apple Podcasts | TuneIn | GooglePlay | Stitcher | Spotify | iHeart Be sure to connect with us on Facebook, Twitter, and LinkedIn, and share your favorite episodes on social media to help us reach more listeners, like you. For additional information around new product development or corporate innovation, sign up for Sopheon's newsletter where we share news and industry best practices monthly! The fastest way to do this is to go to sopheon.com and click here. 

Welcome to Hunters and Unicorns: The Sales Leaders Playbook.   We're here to showcase leaders within People and Culture and explore how the fastest growing tech companies are amplifying performances through increased employee engagement.  By highlighting and celebrating the executives driving the evolution within the highest growth software companies in the world, we aim to uncover:  Why engagement is critical   The importance of diversity, equality, and inclusion   How to achieve true scale by attracting a diverse workforce of A Players  Today we are joined by Hash Basu-Choudhuri, General Manager of EMEA at Cribl. In this episode, we discuss Hash's history in the observability industry, his experiences as first man on the ground opening up EMEA operations at Cribl, and the business plan he executed against to introduce the 18-month-old startup to a brand-new market and territory in 2021.   “Credibility, integrity, and trustworthiness are three things that I think will always stand you in good stead, whether you're in this business or any other business and I've never compromised on those three. You say what you're going to do and do what you're going to say. That's number one. Number two, it's the team, it's never about one man, it's about working together in unison and then, let's be honest, it's about the product.”  Taking us from the early days of cutting his teeth at Sybase – to joining Splunk in the middle of an economic crisis in 2008 – through to his current adventure at Cribl and the entrepreneurial drive that led him to this role, Hash opens our eyes to the change mindset required to succeed in the fast-paced Observability sector as we discuss the benefits of his deep technical background and the key drivers that push him to accept new challenges and continually reinvent himself in different areas of business.   With a variety of tools and techniques for propelling an upward career trajectory in the tech space, listen to this podcast to discover the foundations that enabled Hash to accomplish success as well as his strategies for building sustainable, repeatable, and high growth business. 

In this episode you will learn:Why does Capria Ventures act as both a VC fund and a fund of funds, and what benefits does this approach offer?What is the "state of the art venture capital innovation" that Capria Ventures brings?How does Capria Ventures nurture its partnerships with fund managers across different regions?What are some of the challenges that founders from the global south face and how different are they to the global north?According to Dave, what is the most common mistake made by founders or founding teams?Why is the "spray and pray" investment strategy unsustainable, according to Dave?Why does Capria Ventures focus on the global south, and is it possible for this region to achieve the same level of wealth as the global north over time?AboutDave Richards is Co-Founder & Managing Partner of Capria Ventures. Dave is an experienced entrepreneur, operating executive, and venture capital investor. He co-founded Capria Ventures in 2012 and has since made 60+ investments in early- and early-growth tech startups across the Global South -- India, SE Asia, Latin America, and Africa. Previously, Dave led Unitus Group, a leading early venture catalyst and capital investor in microfinance in the Global South. He has also held business operating leadership roles with RealNetworks, Sybase, and Symantec managing large global teams and building multiple zero to $100M technology-led businesses in digital media, databases, and business productivity tools. Dave received his Bachelor of Commerce degree from the University of British Columbia.

An airhacks.fm conversation with Mary Grygleski (@mgrygles) about: 808X as first computer, Hong Kong was high tech, enjoying space missions, Star Trek and Star Wars, the intriguing registration terminal, writing code in Pascal, 3 GL programming languages and SQL, set theory and SQL, the seven layers of OSI, OSI model, IBM MVS, AS 400 is the opposite of micro services, developers get bored too early, learning X-Windows, working with early Oracle databases, using dBASE, clipper and FoxPro, transarc, stratos tx, Transarc the transaction file system, Transaction Processing: Concepts and Techniques, working on SMTP / MTA, CouchDB and Lotus Notes, the Sun Ultra 30 workstation, starting at Sybase, EA server Sybase / Jaguar, using emacs for Java development, then netbeans, Java EE and the hierarchical class loaders, working on EJB 3 specs, mobile apps with Apache Cordova, reactive systems at IBM, using akka, Eclipse Vertex and MicroProfile, working for datastax and Pulsar, Datastax provides support for Apache Cassandra and Apache Pulsar, separating the compute from the storage, astra the managed cloud platform Mary Grygleski on twitter: @mgrygles

This week we welcome back to the podcast former co-host Eric Trexler, Senior Vice President, U.S. Public Sector at Palo Alto Networks. We examine some hot security topics for the year ahead including growing prevalence of AI/ML automation used for preventative security, continued evolution and impact of ransomware (Did you know the average dwell time is 28 days?!), increasing adoption of people/process/technology approaches, industry consolidation, state and local cybergrants coming online and the opportunities those open up, Zero Trust pros and cons, attack surface management and what's been learned about cyberwarfare from the Ukraine conflict.   Eric Trexler, Senior Vice President, US Public Sector, Palo Alto Networks Eric joined Palo Alto Networks in September of 2022 and oversees the US Public Sector business. Most recently, Eric Trexler was the Vice President of Sales, Global Governments and Critical Infrastructure at Forcepoint. Eric was responsible for Global Go To Market operations to include all components of sales, sales enablement, and field and product marketing. While at Forcepoint, Eric's team doubled the size of the business over a five year period to nearly $400M in annual sales and strategically moved a large part of the business to the Public Cloud. Eric has nearly 30 years of experience in technology across the public and private sectors, including Department of Defense, Civilian, and Intelligence communities, along with International governments. Eric has combined his sales savvy and technical skills with practical knowledge of leadership fundamentals to solve global cybersecurity issues for his customers and the business. Prior to Forcepoint, Eric was the executive director for Civilian and National Security Programs at McAfee (formerly Intel Security). Earlier in his career, Eric worked at [Salesforce.com](http://Salesforce.com "‌"), EMC, and Sybase. He spent four years as an Airborne Ranger with the U.S. Army specializing in communications. Eric holds a Master's Degree in Business Administration and a Bachelor's of Science in Marketing from the University of Maryland at College Park. He was the co-host of the award winning “To The Point Cybersecurity” podcast with over 200 weekly episodes covering various cybersecurity topics, and he regularly writes bylines for cybersecurity and national periodicals. For links and resources discussed in this episode, please visit our show notes at https://www.forcepoint.com/govpodcast/e216

A Note from Marguerita Cheng, CFP® Pro — I invite you to tune in for this week's episode of my podcast and video show, Margaritas with Marguerita, where for 15 minutes, we learn from industry experts how to flex our financial muscles. Today's Topic: Sustainable investing and the rise of the activist investor featuring author John O'Connell Rita asks John:  What is an activist investor? What changes are coming together to cause a rise in activist investors? How is activist investing different from ESG or sustainable investing? What will be the effect of the Rise of The Activist Investor? Meet our guest: John O'Connell has more than 29 years of leadership experience in emerging businesses and mature, established organizations. He started his career designing and developing financial applications at Merrill Lynch and KPMG Peat Marwick. John then transitioned from developing technology into sales and marketing while leading the financial services vertical for Sybase. John was a member of the senior leadership teams for several startups culminating in an IPO and packaging 2 other firms for their sale. He returned to Merrill for several years and until its acquisition in 2008. He held North American leadership positions at Oracle for over 8 years. He was the president of a private FinTech firm and held C-level customer-facing roles at publicly traded InsureTech and FinTech firms. John was inspired to become an author for his three daughters, who are part of the Emerging Wealth Class. "They have solid careers and are interested in growing their wealth, but they were not prepared in school for investing," John believes. "Like many of their friends in the emerging wealth class, they live through social movements, are socially conscious, and want their investments to reflect their values." In his book, John explains that the Emerging Wealth Class will inherit an estimated $30 to $68 trillion in the expected Great Wealth Transfer when their aging parents die and transfer their accumulated wealth to their adult children. "Wealth has an enormous power to change companies and how they behave. "What happens if a company you think is a good investment does not align with your values, or worse, you've invested in them, and the company turns away from your values? How about companies that you believe are excessively paying their executives at the expense of their workforce? How can you change the direction of these companies? The Great Wealth Transfer in the hands of socially conscious investors will give rise to an activist investor movement." Click here to learn more about John: john-oconnell.com. Find his book for sale on Amazon. Learn more about Marguerita Cheng, CFP® Pro: MargueritaCheng.com • Listen to Rita's podcast show, Margaritas with Marguerita, on her radio channel: MargueritaChengRadio.com • Watch all of the show's video episodes on Rita's YouTube channel: www.MargueritaCheng.tv

Darryl Praill is the Chief Marketing Officer of Agorapulse, a social media marketing platform. Darryl is a high-tech marketing executive with over 25 years of experience spanning startups, re-starts, consolidations, acquisitions, divestments and IPO's. He has been widely quoted in the media including television, press, and trade publications. He is a guest lecturer, public speaker, and radio personality and has been featured in numerous podcasts, case studies, and best-selling books. Praill is a former recipient of the coveted Forty Under 40 Award and has held senior executive roles in leading companies including Sybase, Cognos (now IBM), webPLAN (now Kinaxis), and CML Emergency Services (now AIRBUS). He has raised over $50 million in venture funding across multiple organizations and consulted with world-class corporations including Salesforce, SAP, and Nielsen. In this episode, he shares how we can use soft leadership skills to empower teams and drive growth. Insights he shares include: The biggest challenges with revenue growth for companies in the B2B spaceThe place for soft leadership skills for today's executive leadership teamsIs revenue growth the by-product of a handful of attributes? If so what are theyWhat does it take for a CRO to be successful todayIs there a correlation that can be drawn between how tasks are executed and the manner in which leaders develop relationships in and out of a teamHow to build psychological safety in conversations with othersHow to better understand people's motivations in their roles and responsibilitiesDarryl's take on experiential learning in the context of leadership developmentHow best to tackle revenue growthand much much more ....

Do you realize what special gifts and talents you bring to the table in your occupation each and every day? Conversely, can you articulate what frustrates you most in your job? Mike Linch digs in with Patrick Lencioni, one of the greatest modern day authors on organizational health to talk about his latest release, The Six Types of Working Genius. Lencioni shares candidly how God has been the true Author of his story and journey to become one of the foremost voices in the business world, and the author of 13 books that have transformed organizations and peoples' approach to work and relationships.Pat is one of the founders of The Table Group and is the pioneer of the organizational health movement. His books have sold over 6 million copies and been translated into more than 30 languages. As President of the Table Group, Pat spends his time speaking and writing about leadership, teamwork, and organizational health and consulting with executives and their teams.Prior to founding the firm in 1997, Pat worked at Bain & Company, Oracle Corporation and Sybase. Pat lives in the Bay Area with his wife and four boys.

Do you realize what special gifts and talents you bring to the table in your occupation each and every day? Conversely, can you articulate what frustrates you most in your job? Mike Linch digs in with Patrick Lencioni, one of the greatest modern day authors on organizational health to talk about his latest release, The Six Types of Working Genius. Lencioni shares candidly how God has been the true Author of his story and journey to become one of the foremost voices in the business world, and the author of 13 books that have transformed organizations and peoples' approach to work and relationships.Pat is one of the founders of The Table Group and is the pioneer of the organizational health movement. His books have sold over 6 million copies and been translated into more than 30 languages. As President of the Table Group, Pat spends his time speaking and writing about leadership, teamwork, and organizational health and consulting with executives and their teams.Prior to founding the firm in 1997, Pat worked at Bain & Company, Oracle Corporation and Sybase. Pat lives in the Bay Area with his wife and four boys.

About the author Pat is one of the founders of The Table Group and is the pioneer of the organizational health movement. He is the author of 13 books, which have sold over 6 million copies and been translated into more than 30 languages. As President of the Table Group, Pat spends his time speaking and writing about leadership, teamwork, and organizational health and consulting with executives and their teams. Prior to founding the firm in 1997, Pat worked at Bain & Company, Oracle Corporation and Sybase. Pat lives in the Bay Area with his wife and four boys. Source: https://www.tablegroup.com/pat/#pat  About the book Pat's new book, The Six Types of Working Genius, is on track to be his biggest and most impactful book yet. In classic Lencioni fashion, Pat brings his model to life in a page-turning fable that is as relatable as it is compelling. He tells the story of Bull Brooks, an entreprhttps://www.stephsbusinessbookshelf.com/the-five-dysfunctions-of-a-team-by-patrick-lencioni-why-you-need-to-embrace-conflict/eneur, husband, and father who sets out to solve his own frustration at work and stumbles into a new way of thinking that revolutionizes the way he sees his work, his team, and even his marriage. Bull's story is indicative of every man and woman who is striving to avoid burnout and find fulfillment, dignity and success in their work. Beyond the personal discovery and instant relief that Working Genius provides, the model also gives teams a remarkably simple and practical framework for tapping into one another's natural gifts, which increases productivity and reduces unnecessary judgment. Whether you're a team leader or entrepreneur, a front-line employee or executive, or a school teacher or stay-at-home parent, this book will help you find more joy, fulfillment and success in your work and your life. Source: https://www.workinggenius.com/book  Three big ideas The 6 types Know your category In it together Other books of Pat's I've talked about Five Dysfunctions of a Team (my favourite) The Ideal Team PlayerSupport my book habit: https://www.buymeacoffee.com/stephsbookshelfSee omnystudio.com/listener for privacy information.

Layoffs are simply a part of business. Over the years there have been millions of workers let go and it's always a difficult, painful process. In this podcast I give you my perspectives on the process, the role leadership must play, and how to deal with the topic if you are the one losing your job. I also give you my own perspectives on hiring, which is the mirror image of layoffs, and what I think is going on at Twitter. Finally, I took a few minutes to share my personal experience with layoffs at IBM, Sybase, DigitalThink (where I was the victim), and my own company. I hope this podcast gives you some perspective as a leader, HR person, or individual dealing with this issue. And let me remind you the Irresistible companies deal with this a very unique way.  (They hire slowly and have a very deliberate process to make sure all new hires "increase productivity" and don't "slow the company down.") More Background History of biggest layoffs in the US List of latest 200,000 layoffs in Tech (real-time updates) Irresistible: The Seven Secrets Of The World's Most Enduring, Employee-Focused Companies Elon Musk Is Bad At This (The Atlantic) Mark Zuckerberg Says "He's Sorry" For The Layoffs

What are the areas of professional development that Sales Engineers are interested in but that many Sales Enablement teams miss? How can Revenue Enablement teams generate excitement and boost morale within Sales Engineering teams? What do  customers say they want Sales Engineers enabled to  do well?John Care, Author and Managing Director of Mastering Technical Sales shares his insights with me in this 2 part series. In Part 2 we focus on discovering and developing professional development pathways for SEs that focus on the experiences and skills they're most interested in developing. Since 35% of SEs say they'd like to go into leadership we also cover how to help them prepare for that career goal.During his career, John built world-class sales engineering organizations at Oracle, Sybase, Business Objects, Nortel, CA Technologies, and HP. His responsibilities have varied from an individual level up to a VP of Presales running teams of over 200 people. He also has diverse experiences as both a quota-carrying salesperson and a senior IT executive/ CIO listening to salespeople and presales engineers trying to sell him their “solutions.”

How do Sales Engineers learn differently? Is their attitude towards training different? What are the onboarding needs of an experienced vs. a novice SE?  When should the handoff from the Enablement team to the SE leaders occur? What are the 3 critical legs of onboarding SEs?John Care, Author and Managing Director of Mastering Technical Sales shares his insights with me in this 2 part series. In Part 1 we focus on defining and understanding the Enablement needs of SEs and how to design an effective onboarding experience for them.During his career, John built world-class sales engineering organizations at Oracle, Sybase, Business Objects, Nortel, CA Technologies, and HP. His responsibilities have varied from an individual level up to a VP of Presales running teams of over 200 people. He also has diverse experiences as both a quota-carrying salesperson and a senior IT executive/ CIO listening to salespeople and presales engineers trying to sell him their “solutions.”

Shampa Bagchi comes from a family of entrepreneurs who all value living life to the fullest as well as helping to improve our world. Shampa, born in India, moved to the United States after getting a Masters's degree in computers.   In the mid-1990s she saw a need to improve the way companies worked with customers and developed one of the first easy-to-use and inexpensive customer Resource management systems, CRM. Throughout her career, as she tells us in our episode, she has worked throughout her work life to improve processes and make products and systems to simplify systems.   Shampa's stories are fascinating and insightful. I believe you will come away from this episode realizing more than ever that being unstoppable is really something that is available to all of us if we choose the path to drive ourselves just a bit harder to accomplish goals.   About the Guest: Shampa Bagchi is the Founder and CEO of ConvergeHub (www.convergehub.com), a Customer Lifecycle Management CRM software that powers business growth. Shampa specializes in taking ideas from concept to reality and is passionate about helping businesses grow by utilizing the power of technology to solve complex business challenges.   She also founded Corelynx (www.corelynx.com), a boutique software development and strategy agency providing innovative business solutions to growing organizations.   Shampa holds a Master's degree in Computer Science and has been at the forefront of the technology revolution in Silicon Valley for more than two decades. She has worked with large enterprises such as Cisco Systems, Siemens, etc. as well as hundreds of small and medium businesses to build software products and applications that empower businesses and change lives.   Being a ‘woman in tech' long before #womenintech became a movement, Shampa is passionate about technology education for women. She has founded Onward Academy (www.onwardacademy.in), a software training institute in India, with the goal to increase the participation of women in the tech industry.   Shampa writes a blog called ‘The Spark' (www.thespark.work) where she explores the intersection between business, technology, and people… and the power of little things to make a massive difference in any of these areas.   She also writes and posts videos on a regular basis on LinkedIn and can be followed on https://www.linkedin.com/in/shampabagchi/         About the Host: Michael Hingson is a New York Times best-selling author, international lecturer, and Chief Vision Officer for accessiBe. Michael, blind since birth, survived the 9/11 attacks with the help of his guide dog Roselle. This story is the subject of his best-selling book, Thunder Dog.   Michael gives over 100 presentations around the world each year speaking to influential groups such as Exxon Mobile, AT&T, Federal Express, Scripps College, Rutgers University, Children's Hospital, and the American Red Cross just to name a few. He is an Ambassador for the National Braille Literacy Campaign for the National Federation of the Blind and also serves as Ambassador for the American Humane Association's 2012 Hero Dog Awards.   https://michaelhingson.com https://www.facebook.com/michael.hingson.author.speaker/ https://twitter.com/mhingson https://www.youtube.com/user/mhingson https://www.linkedin.com/in/michaelhingson/   accessiBe Links https://accessibe.com/ https://www.youtube.com/c/accessiBe https://www.linkedin.com/company/accessibe/mycompany/ https://www.facebook.com/accessibe/       Thanks for listening! Thanks so much for listening to our podcast! If you enjoyed this episode and think that others could benefit from listening, please share it using the social media buttons on this page. Do you have some feedback or questions about this episode? Leave a comment in the section below!   Subscribe to the podcast If you would like to get automatic updates of new podcast episodes, you can subscribe to the podcast on Apple Podcasts or Stitcher. You can also subscribe in your favorite podcast app.   Leave us an Apple Podcasts review Ratings and reviews from our listeners are extremely valuable to us and greatly appreciated. They help our podcast rank higher on Apple Podcasts, which exposes our show to more awesome listeners like you. If you have a minute, please leave an honest review on Apple Podcasts.     Transcription Notes Michael Hingson  00:00 Access Cast and accessiBe Initiative presents Unstoppable Mindset. The podcast where inclusion, diversity and the unexpected meet. Hi, I'm Michael Hingson, Chief Vision Officer for accessiBe and the author of the number one New York Times bestselling book, Thunder dog, the story of a blind man, his guide dog and the triumph of trust. Thanks for joining me on my podcast as we explore our own blinding fears of inclusion unacceptance and our resistance to change. We will discover the idea that no matter the situation, or the people we encounter, our own fears, and prejudices often are our strongest barriers to moving forward. The unstoppable mindset podcast is sponsored by accessiBe, that's a c c e s s i  capital B e. Visit www.accessibe.com to learn how you can make your website accessible for persons with disabilities. And to help make the internet fully inclusive by the year 2025. Glad you dropped by we're happy to meet you and to have you here with us.   Michael Hingson  01:20 Yep, it is that time again. Welcome to unstoppable mindset. I am Michael Hingson, your host glad to be here. Hope you are happy to be here probably are because you're here, right. So wherever you are welcome. And we really appreciate you and hope that you enjoy the next hour. We have a fascinating guest. We're actually starting the recording of this podcast 10 minutes late because we've just been sitting here chatting Shampa Bagchi  is a woman very involved in tech, she has formed a company called convergehub. And she, and actually convergehub is a software. Well, not a software product specifically, but it is a customer resource management tool. And she'll tell us about that. So I don't want to mess up my description more than I have. But she's also formed a company called core links, which is a system by which she helps other customers write software and do things that they need to do to make their company work the way it should. And she has a great amount of experience in the world of computer science. She's been involved in Silicon Valley Tech for a while. She has a master's degree in computer science. We're jealous, and lots of other things. So Shampa   Welcome to unstoppable mindset after all of that. And   Shampa Bagchi  02:42 Michael, thank you. Thank you. I'm glad to be here. Thank you so much for inviting me.   Michael Hingson  02:46 And you notice that I didn't use queen to the world, which I said I could use. And   Shampa Bagchi  02:51 then thank you for that too.   Michael Hingson  02:53 You're safe? Well, I really am fascinated to learn. Let's start with more about you and what you did growing up and how you got to the point of being so interested in involved in tech.   Shampa Bagchi  03:04 Yeah, of course, I actually started software programming in college. And like, Well, initially, I always had an interest in science and my initial interest, I wanted to go into nuclear physics. So physics was my first love. And then. And then   Michael Hingson  03:27 my master's degree is in physics. Oh, wow.   Shampa Bagchi  03:30 So I have a bachelor's in physics. And then I went on to do a master's in computer science. So wonderful. Yeah, it's a really great subject. That's   Michael Hingson  03:40 fair. Yeah.   Shampa Bagchi  03:42 And but then in a while, I know when I just started taking some computer courses. And once I wrote my first software program, I was totally hooked. And the main reason I really liked it is because it gave me this ability to take a complex problem. And then kind of, you know, break it down into little bits, and then solve it and kind of put the solution back together again. So I really, really was interested in that. And then that was a time when computers as a career, it was just opening up, it was just beginning. And I wasn't thinking so much as career itself. But more in terms of it was really because in that time when you go into a career, most of the time, you could only influence a certain amount of people, right? Only the people around you. But what I realized is using computers, you could build a program with somebody sitting on the other corner of the world use to solve this problem, which you probably won't even think about. And just that idea of being able to touch people whom you don't even know you know, whom you haven't heard of. It was so fascinating to me that I had to get into that, and I had really to do it so so and even today, even though I don't write software code anymore, but just that idea of building software products, which people all over the world use to solve their problems, it's, it's really interesting to me, I feel like I'm touching their lives.   Michael Hingson  05:14 There you go, Well, what do you do specifically today,   Shampa Bagchi  05:19 but today, I'm the CEO of convergehub. So I check of all trades, really in the company. So I'm handling the product development. I do oversee that I do some marketing, and even the other financial stuff that I have to do on a daily basis. So   Michael Hingson  05:39 not boring stuff. Yeah,   Shampa Bagchi  05:41 exactly. My very necessity.   Michael Hingson  05:44 Yes, yeah. It is part of what has to be done. And at least you Well, I don't know whether you have the patience or not. But you certainly seem to be able to, to put up with it all. Not always. But I tried, Does, does your coding experience help you in doing all the other things that that you have to do in the company? Or maybe a better question would be how does that past experience help you?   Shampa Bagchi  06:14 That's actually very interesting. Now that I think about it, it really does. Because when you are coding, you are taught to kind of look at a problem, I kind of step away from it, and just look at it as a problem and then start breaking it down or tinkering with it, you know that as a challenge itself, you cannot solve the whole thing. But when you break it down, and we address it one by one, you are able to solve it and you without really getting too involved with with taking a step back. So if you take that approach to any other work that you have to do any other experience or challenge that you're going through, I think that really helps you solve it in a better way.   Michael Hingson  06:58 Yeah, that's that's kind of what I was thinking that you would say I remember when I was in undergraduate physics, and of course it it then followed on but an undergraduate physics, oftentimes, professors would say, pay attention to the details. It's all about the details. It isn't just the math, for example, it's the units. And if the units don't work out, right, then you probably are doing something wrong. So you really need to look at the details. And I've always felt that that background in physics, even though I am not doing anything specifically in physics, the background has helped a great deal for me in everything that I do, because I've learned to pay attention to a lot of the details and appreciate the value in doing that.   Shampa Bagchi  07:47 Absolutely, absolutely. I think that's what it is. And I had, I had read somewhere that no education is what survives after what you learned has been forgotten. So I guess that what it is it kind of builds into you and then you know, you keep using it and other experiences in your life.   Michael Hingson  08:05 Yeah, I've talked to a number of people on this podcast who say, the reoccurring theme is you should never stop learning.   Shampa Bagchi  08:14 Absolutely. I totally agree. But yeah, it's   Michael Hingson  08:17 kind of one of those things that that one needs to do. Well, you went off and where do you get your Masters from? By the way?   Shampa Bagchi  08:24 Well, I did my masters from India. Okay. Yeah. And   Michael Hingson  08:28 then you then you came over here at some point. And, and you you started working now, did you code when you first came over? How did what brought you over here?   Shampa Bagchi  08:39 Yeah. So in India, after I did my masters, I started working in a company and that company was then I know, deploying some, you know, software programmers here. So I came as a part of that. And I literally landed in us with what, less than $150 or so. And a job of course, and went from there. So I know after I worked. Initially, I started working with a large enterprises like Cisco Systems, pyramid technologies, which was a part of Siemens. And yes, I was doing programming in Cisco Systems, I was part of the sales, the customer facing side of the software, really, you know, the sales, customer service. And in those days, there was no such thing as customer relationship management software, it didn't even exist. So what we were doing is we were taking Oracle Applications, the ERP package, and we were customizing it to build those pieces in and Cisco eventually, you know, it came it became the first company who did the online ordering the entire online ordering, where an order from a customer would go in and to be fulfilled without the touch of human hands. So and this was Very, very early days, and I was really fortunate to be a part of that big hole team.   Michael Hingson  10:05 What kind of what timeframe was that?   Shampa Bagchi  10:07 So this was kind of mid to late 90s, actually 9099 kind of timeframe. Yeah. So and then after that, I started working on a few startups, but then always wanted to open my own company. So that's when I launched core links. And well as part of callings, what we do is we build custom software. We are a software strategy firm. So we provide like a fractional CTO services, strategy services, software development for both products as well as software applications. So and we did that, and even while we were doing that kind of note, notice that a lot of the requests that we were getting for building the software center around the same thing about New Customer Relationship Management, how do I handle my customers war? How do I support my customers? How do I do lead management? So we were building constantly, we were building software for that for all our clients, and it began to occur to me, you know, I started digging in and found out that really, you know, there was no product in the market which suffice that need for customers, there were really two types of customer relationship products in the market at that time. One was really huge, big blood scale software, you need a PhD to implement that. And other than that, there was these no small little contact management systems really no dumbed down products, which really didn't suffice the need of, you know, small and medium businesses, because they had their complex processes, but at the same time, they can spend that kind of money, you know, to, to implement such a large scale software. So that's why we decided to build convergehub, which would service these kinds of customers. And yeah, so we started building convergehub, and which is right now, complete customer lifecycle management system, it serve right from the beginning of the customer journey, till the end is supported within convergehub.   Michael Hingson  12:18 So is it is a web based system then? Or?   Shampa Bagchi  12:21 Yes, it is. SAS product software as a service product? And yes, it's completely online.   Michael Hingson  12:28 Cool. How does it? Well, so now we have other things like Salesforce and so on, how does it compare with those kinds of products? Which of course didn't exist back in the early days?   Shampa Bagchi  12:40 Yes, no, when I was working in those, Cisco and those other large enterprises, Salesforce didn't exist. By the time I had to know founded convergehub, Salesforce did start up. But Salesforce was in that category of large scale software, which needs a lot of effort to implement, which small businesses didn't necessarily have. So yeah, so convergehub is kind of isn't the same space does similar things, but in a much more simpler way. So that you can get that you are able to, you know, establish you are able to serve your complex business processes, but you really didn't have to put in so much effort to implement them. The implementation is much simpler.   Michael Hingson  13:26 I remember when selling tape backup products for quantum Corporation and others before it, and so on, working with Wall Street, of course, they used both Oracle and Sybase and Sybase was very unformatted fields and so on. But those firms essentially created their own software within those database structures, to do the same kind of work in terms of managing customers, managing orders, managing all of the things related to that. And the Securities Exchange Commission required it of course of Wall Street, because they needed you to have a way where you track all your orders, which Wall Street firms would want to do anyway. And then to keep them for seven years off site. So we provided the tape backup products, and they would work with products like Elgato and other kinds of tools that would communicate between their systems and the backup products that we provided. So a lot of moving parts.   Shampa Bagchi  14:26 Yeah, yeah, absolutely. And, yeah, it's come a long way since then, but it's always fun to think back to how quickly we've changed how much   Michael Hingson  14:37 yeah, as I was saying to somebody not too long ago, I remember when a disk crash was a real disk crash. Yes. Where you had a 16 inch platter and they had was micro centimeters above it, and if it fell, it was a very noisy situation and all your data was lost. was pretty amazing. We've come a long way. And we'll continue to that's what kind of makes this technology era fun. On the other hand, even with you starting in India, and so on, tell me a little bit about how women were viewed in tech. And I would think that you were kind of a breakthrough person to deal with some of that.   Shampa Bagchi  15:19 Yeah, actually, when I started, in college, when I went into software, we didn't have that many, you know, women in technology at that time, but it's not like I faced a lot of resistance to it. But there just weren't that many software, it was a very new subject at the time. And, but then I was so fascinated with it, I wasn't really looking at the gender, I just wanted to build software. So I wasn't really looking at, you know, how many you know how easy or hard it would be for me to get in? But yeah, since then, even after coming, you'd be surprised, or even after coming into Silicon Valley, I did face some challenges. There. It's not so much as I don't think people really resist you, because you're a woman. It's not that people say that, okay, you know, she's a woman, I'm not going to listen to what it what she does, I'm not going to give credit or and I'm going to cause resistance, not really, but it's more sort of a mindset, you, there's this assumption kind of a thing, and that you probably aren't as good, you know, you probably won't be able to do it. And then you know, you have to keep proving yourself all the time. So and then, you know, it's when you prove yourself, it's not that people won't accept it, you know, people do. So I would think it's more a matter of just education and getting used to it, rather than you're actively making sure. Women don't get the chance.   Michael Hingson  16:47 But I think that's true of people who are, are different than what is viewed as the norm in general. I mean, in terms of blindness, for example. There's, there's resistance. And the general assumption is that if you're blind, you can't succeed nearly as well as sighted people can. And that that view has been around for a while, it does take a lot of educating. And you do have to continuously prove yourself to be able to accomplish tasks and and grow in the industry. It isn't that you can't, but it certainly tends to be harder, because, as you said, it's the mindset of what people believe you can and can't do. And unfortunately, in the case of well, and in some ways with women, too. But in the case of blind people, for example, the unemployment rate among employable blind people is still in the area around 70%. And it's not because people who are blind, who happen to be blind can't work. It said, others think they can't work in that prejudice still exists.   Shampa Bagchi  17:58 Oh, I totally don't get that. And, you know, interestingly, I had had an encounter, which this was, this was a while ago, I was in college at the time, and I was kind of, you know, I think I had gone down for some internship returning home, got down from the bus. And there was this blind person who had traveled with us who also kind of got on from the past, and there was this road to cross. And He was looking around and he asked for help. He said, Can somebody please help me cross the road? And the house was full of people. So so many people had not on boarded the bus, but it was kind of really strange that although he was asking, and he was asking confidently, but nobody, it's people were hearing it, obviously, they were hearing it, they were sort of pretending not to hear it and going their own way. And it took me by surprise, not just the people's reaction, but even that person's reaction because he was very confident he was not he, there was no kind of he was not submissive. He was not even if although he was asking for help. He was doing it so confidently. I thought it was the other side. The people who should have been more confident probably weren't not confident. They didn't even have the confidence to step forward and just helping him cross the road. So I watched that for a little while. And then I decided to step up. So I went to him. I said, Okay, come on. I took his hand, and I just had to cross the road I want I asked if he wanted help just getting home. And he said, Oh no, I live close by I can manage from here. I just needed help crossing the road and he just went about his way confidently. You couldn't even tell that he was blind unless you actually looked at his stake. So that experience really stayed with me that really, you know, this person was so confident why he was all he needed was a little bit of help, you know, why wouldn't I know anybody do that?   Michael Hingson  19:56 Chris, the other thing that would be helpful is he could You're out how to cross the road. I mean, I used to live in Winthrop, Massachusetts, and every day, both going to the bus and getting off the bus coming home. We had a bus stop that was across the road from the entrance to my apartment complex. And it was just in the middle of the road, right. So there wasn't like a major street that the bus stopped at, there was a bus stop, and it was right in the middle of the street. And there are tools to use it, it was a little bit daunting until I figured out that, hey, one thing I can do to cross the road is to follow other people and listen to them as they are crossing. And the other is to wait until the bus leaves so it's quieter, and then listen to traffic. And when I don't hear traffic coming across in front of me for at least a little bit a period of time, and I don't hear anything that sounds like it's close then to go across the road. But it it is a it is a process. And it can be it can. It can be scary. But it can be daunting if you really don't learn to you know, to do that. So I'm I'm a little bit curious why he had some issues with being able to cross the road. And perhaps he didn't have enough hearing to be able to do that. Who knows?   Shampa Bagchi  21:26 Oh, actually, I think I know, it's probably because of this. Was it India? Yeah, it's so loud and so noisy and so much traffic.   Michael Hingson  21:35 And there was no, no low in the noise.   Shampa Bagchi  21:39 Yes, exactly. Yeah. So that was very, very chaotic and very, very noisy the entire time. So he couldn't use noise as a as a market news   Michael Hingson  21:46 noises. Yeah. So the only thing he could possibly do if he could hear it is to just listen to other people. And as they're going across, stay right behind them. But still it's an issue. Did he use a cane or anything like that? Yeah, he   Shampa Bagchi  21:58 used a cane.   Michael Hingson  22:00 Good that because that would would certainly help. But you know, everyone is different. And certainly the noise factor is a big issue. I've been in New York, on street corners where there are well defined crosswalks and well defined ways to go. But it's so noisy, that it's even here hard to hear the traffic going the way I want to go. And you know, what we do is we listen, and when the traffic is going the way we want to go, then we cross. But sometimes the noise can be so loud around us. And even that's hard to hear. So there are always challenges. But it doesn't mean that we can and that's part of the problem is that sometimes people would go well, you just could never do that. Because you're lying. Well, I can but let's let's talk about the sun being in your eyes, and how well you're able to see when the sun's coming right at you. You know, we all have challenges, of course. So good for you for helping. Thank you. But it is an issue and it is a challenge that we have. Well, so you went off and you got your your master's degree in computer science and you came over to the US. That must have been maybe the the way I would put it is quite an adventure. Just getting here at all. Oh, yes. It was totally new for you.   Shampa Bagchi  23:20 Yes, it was absolutely new for me. And then yeah, getting into tech industry and immigrant brown woman starting to work in the tech industry. It wasn't easy. But then you learn as you go, it was you know, there are challenges, you know, you start looking at? Yeah, and then there are there are challenges. And then there are solutions. And it's, you know, people to help out. And it's just, I think a lot of it is also about how much you like the subject and how hard you're willing to work. And if you have that, I think all other challenges, you know, you're you're proud to be able to work out.   Michael Hingson  23:58 But you had a mindset that you were going to work it out you were going to try to do that as opposed to letting it all overwhelm you.   Shampa Bagchi  24:06 Oh, yeah, absolutely. That's, I think it's also a little bit about being able to know that yes, you will be able to do it. And ultimately, it's going to work out it maybe you can just try to look a little bit into the future and say, you know, here I am going to do it. This is just a process, you know, just a few challenges, which I will have to go through. Everybody has their own challenges. These are mine.   Michael Hingson  24:30 Yeah. And that's the real point, isn't it? Everyone has their own challenges and, and challenges aren't the same for everyone.   Shampa Bagchi  24:40 Absolutely. Yeah. Totally agree.   Michael Hingson  24:42 So you, you made it over you started and you started doing doing technology stuff and, and all that. So how how long was it before you started working essentially for yourself?   Shampa Bagchi  24:56 Oh, I started working for myself or Round, let's say 2000 to 2003, I think timeframe. So that's when I started kind of consulting, no going solo started working on smaller size project and a year or so after that I launched callings. So that's when, yeah, so slowly that grew. And we started getting more projects. And then I started having a team. We formed a team in India too. So, and I started off loading some of my work to them. And slowly the team grew. And yeah, so that's how things took off.   Michael Hingson  25:39 What were some of the early projects like that you started? And that you use core links to develop?   Shampa Bagchi  25:46 Well, we were always working in the beginning, we were mostly working on software applications or so yeah, one of the interesting one was in the insurance industry, I remember this was this was way back. But in a we were kind of, you know, comparing different insurance products. And this was for car insurance, if I remember correctly. And and it was really advanced for its time, too. And we were kind of, you know, giving there was some hundreds of points on which, you know, you could compare insurances. So usually, when you're reading an insurance, you don't even know you don't even look at the fine print. And this was kind of a technology where, which would help you compare insurance without really having to look at the fine print. So. So there's that that was one, there was another one for the FinTech industry that we were building the entire end to end process for fintech. So yeah, some for some very interesting projects. But in the beginning,   Michael Hingson  26:41 what kind of language or coding did you use to develop those?   Shampa Bagchi  26:45 At that time? We were using PHP, and we use MySQL, as a database,   Michael Hingson  26:52 SQL servers and all that. Yeah. What do you use now? How's it evolved over the years?   Shampa Bagchi  26:59 Yeah, now, I'm not coding anymore. But my team user uses Node we use young Angular. So yeah, there's MongoDB, we use. So a lot, it's changed significantly, even the way you code has significantly changed significantly, it's a lot more modular. And at that time used to write 1000s of line, of course, a lot of very, very monolithic kind of code. Now, it's so much more modular, it's a distributed, so things have changed completely. But it's kind of fun to watch my team, although, you know, I don't get fat involved into the day to day process anymore.   Michael Hingson  27:39 You do you have enough and you keep up with it. So you could if you needed to be involved in the process, I would assume?   Shampa Bagchi  27:45 Yeah, absolutely. Absolutely. And, you know, I still have my, you know, kind of, you know, and in there, I'm have daily meetings with the team. But right now, my perspective is more from that of a user from that offer no customer how the customer experience, what will an user go through. So that's my perspective, rather than Wow, this is cool. You know, this is nice bit of technology, let's use it. I don't think of thinking of it like that anymore.   Michael Hingson  28:10 But it's good to be able to take the user perspective, and it's good to have that in a company, because then you, you really get to understand it from the standpoint of those who are going to be directly involved with an encounter of your products, as opposed to just creating them and pushing them out the door without having that understanding, I would think, Oh, yeah,   Shampa Bagchi  28:29 absolutely. And that's somehow you mature, because, in the beginning, that's how you kind of know, especially from from a tech background, you can do you not think, no, take a school, and, yeah, so just try to use anything, and I see my team, still trying to do that I have to push back on it, just because it's the user who is the most important person here, and you know, whatever that takes, technology is good, as long as it's serving the customer. And really, I would say, you know, we are we are coming up with a new release of convergehub. And what we are trying to do here, you know, I'm really trying to put in the human perspective into it more than anything else, because from my experience in the software industry from a very long time, what I'm seeing is there is really no b2b or b2c, or you know, anything like that anymore. It's really a matter of a human being using a product, it's a person using a product, you know, whatever else, you know, from whomever, to whomever, it's still ultimately your person using it. So that kind of knowledge really comes with experience. And that's what how we are building convergehub. So our idea is that using convergehub, you know, sales and marketing and customer service, all that is wonderful. And our users will be doing all of that the features are there, but more so what we would like our user to do is to be able to use the product to make a difference. So he is able to make a difference right Ah, where he is at, you know, whatever he or she is doing, he should be able to do it better do it in such a way that no maybe do it quicker and do it to build better businesses and I hope, better communities, ultimately,   Michael Hingson  30:13 one would hope. Yes. So when did you if you will graduate from quarter links, and so on to convergehub, although you do both, but when did when did converge on first come into existence?   Shampa Bagchi  30:29 converge jobs release was the first release was somewhere around I think we started getting customers around 2017 or so although it was released a little bit earlier in the market around 2015 2016. But that's when we were it was the very first release, we started ironing out all the bugs, I'm a bit of a perfectionist, so I didn't really wanted to push and sell the product until the bugs burning out the or the features were built in. So then we started getting customers in the 2016 2017 timeframe, and it went from there. And now we are getting into the next release the next version of convergehub.   Michael Hingson  31:06 I will bet however, that no matter how much you did to perfect it, and ironed out all the bugs, that once you actually released it, your users started finding things that you guys didn't discover.   Shampa Bagchi  31:20 Oh, yeah. You would have been that better. So yes, there was our software is basically a work in progress. You know, you can never have 100% Perfect software by the time you have the bugs and there are more features, you're building it and those new features will have some bugs. It's always work in progress. No, no company, no software ever built as an IT person. Everything all bugs ironed out. But you try. And what you really do really hope is that the bugs that you do still have aren't hampering the main activities of your users. So if it's, you know, really hampering their productivity with not letting them do what they would like to do in the software, that's that's when it takes priority. And that's how we prioritize bugs to know which ones to fix versus which ones to kind of put on the backburner.   Michael Hingson  32:14 You're now you're in California, right? You're in the Silicon Valley? Yes. So you watch some of the same TV commercials that I do if you watch TV at all. And actually, I saw it again this morning. There is someone who has been putting out some commercials that are just slamming Tesla, because they say that the autonomous vehicle software in Tesla is dangerous, and Congress should stop it and so on. And he's made that his primary focus in his Senate campaign. It's It's fascinating, not withstanding the fact that Tesla hasn't, as I understand it, at least the last time I checked, released a totally autonomous vehicle version of the software. But the reality is, it's always going to be a work in progress to do what Tesla has already done so much of to make their vehicle work in, in a way to greatly assist drivers. And it's just fascinating to see that kind of a mindset that just wants to put a stop to all of that kind of stuff, when that makes no sense at all.   Shampa Bagchi  33:20 Oh, yeah, absolutely. I totally agree with you there. Because if it's a software, there's always going to be bugs. So that's for sure. But it is true that in certain industries, those bugs have a bigger impact. Because if you are not careful, you know, when you're driving a car about code, you know, injure somebody, or worse. But at the same time, not similar to that is medical profession. And so anything, any software in the medical profession, you have to test very, very thoroughly because there are human lives involved. But at the same time, you at some point, you have to do your best, and you have to completely test thoroughly. And I think incrementally you do have to release the software, otherwise, it just doesn't happen. Right. So and knowing that it is software and there will be bugs, and we just do our level best to make sure that that bug doesn't have the worst kind of impact.   Michael Hingson  34:17 While being an equal opportunity abuser. Of course, my immediate reaction is if we're going to talk about what goes on with Tesla, let's talk about people driving in general, and there's some value in replacing them. Exactly. You know, the I don't know, my I'm amazed at my wife. Now my wife uses a wheelchair. She uses hand controls and she drives really well. We have had one accident in the almost 40 years that well. We've had a couple but there was one accident that we were probably more responsible for than anything else. We had one where we were actually going to anniversary dinner, and we came over a hill and there was a place where a car should not have been stopped on the road and there was no way to see it ahead of time. But this young lady who was a teenage driver had just stopped in the middle of the road. And we we bumped her before we could stop. So it was a brand new car and a dent in the car. But we had a time where we were driving, and actually, we, a gust of wind kind of blew us over. And we brushed against a piece of heavy equipment and then went back across the road. But partly she was also trying to avoid a trailer that had come up on us. We had we had, she saw the truck that was pulling the trailer but didn't see the trailer was in her blind spot. Well, anyway, but she but she dealt with it. But there are so many people on the road that are so impatient drive so aggressively. And I don't know how they survived because they they don't do anything to recognize the courtesy and that what we used to call in the world defensive driving, you know, we don't do that anymore. No. Yeah, yeah. So I'm all for taking the driving away from drivers. And in as soon as we can, putting it into a much more autonomous vehicle kind of environment, because too many crazy people are out there driving on the road.   Shampa Bagchi  36:14 Yeah. And I think you're absolutely right. So when once you know we get into that autonomous driving becomes the main thing. You know, what, what I see here, what kind of the research says that they are way safer than just these crazy people or drunk people is not driving a car, at least the machine want to drive drunk driving? You know,   Michael Hingson  36:35 we are kind of in the forefront of it. And we're new into it. But it's going to happen. It has to absolutely it has to happen. So in so there's a lot of artificial intelligence and machine learning that goes into all that. And speaking of that, how does that play into both you and convergehub, and quarter lengths and so on? Do you use much artificial intelligence to help in the development or testing of your software and so on?   Shampa Bagchi  37:03 Yes, it's not so much in the development itself. But we are planning the new version of convergehub, we are planning to put artificial intelligence in there and have this AI to do a lot of automated stuff, which initially would have to be manual. And then of course, now there is so much data, data analytics, and all of that is going to be built into the new version of convergehub. So all the definite features are not ironed out yet. And what we are going to give, but there is no one thing for sure is that we are going to have a completely channel, less conversations. So regardless of you know, like like today's users, they could be using one channel at one point of times, and you know, completely switch channels, the other point of time. So you know, from email, to phone, to Twitter, to, you know, to texting. So all of these channels should appear as if it's still a conversation as if it's a one conversation thread the whole time. So that's and there is so much insights that you can figure out from those conversations, and you know, many other companies have started working in it on it. It's not perfect, nobody has perfected it. But you know, we are definitely not going to work on that and see, you know, where that leads us. So, for me as a tech person, it's like both ways. And one is, of course, no, this is the latest technology, this is where we are going to be we have to be there. But that ain't the model remain the same, you know. So it's ultimately it's about how the technology will help you do a better job at whatever it is that you're doing. So as long as we can do that, we balance that, you know that that's the ideal way to go. I would say,   Michael Hingson  38:48 again, we're in a bleeding age environment, where so many of these things are new, and we're just learning about the minute you're in 100 years, it's gonna be a totally different world. And then we'll have other things that are new, but But what we're talking about today, as kind of in the formative era will all change. Yeah, yeah.   Shampa Bagchi  39:09 And it's, and the change is coming faster and faster. You know, it's exciting to see a little bit scary, too. But as time goes by, it's just it's the pace is accelerating. You know, you don't even know I mean, why 100 years, we don't really even know what's coming up in the next five or 10 years from now. So that's exciting and scary at the same time.   Michael Hingson  39:30 Sometime in the next 100 years. Somebody's going to probably develop antigravity and maybe we'll even get Star Trek transporters.   Shampa Bagchi  39:38 You know, I'm just waiting for that, you know, beat me up, Scotty.   Michael Hingson  39:42 Yeah, I'm waiting for that. That would certainly take care of a lot of the driving issues.   Shampa Bagchi  39:48 That's it. That's it. No more driving. I'd love that.   Michael Hingson  39:53 Oh, yeah. Well, we could use the roads for other things. Robert Heinlein wrote, a short story called The roads must roll back In the early 1950s, and instead of driving, roads all moved, and were long, almost like conveyor belts and even going from one end of California to the other. It was a it was a fascinating story. It's a it's a really interesting story to read, because everyone used rolling roads to go anywhere and off of the main roads. There were other roles that took you roads that road that took you where you needed to go. It's a fascinating story.   Shampa Bagchi  40:25 Yeah. Wow. That's an interesting concept. So cars don't need to drive. It's the roads that are doing the driving for you.   Michael Hingson  40:32 Right. Yeah. To go hunting. It's called the roads must roll by Robert Heinlein   Shampa Bagchi  40:37 definitely look at it. Yes.   Michael Hingson  40:39 It's a short story. You can read it in 15 minutes.   Shampa Bagchi  40:41 Oh, look it up. Yeah. I was reading about another fascinating concept to somewhere is that you know, a car start charging themselves as they drive. So you know, you have some sort of, you know, I don't even know if that's the real roads are going to be built such that in the cars while they're driving, they get charged. So you really don't need to charge the cars anymore.   Michael Hingson  41:02 I think? Well, I know, somewhere in this area around San Diego, I think it is there was a road that had some sort of cable going through it that helped provide guidance for the car. But I don't remember whether it charged or not. I think it was pre a lot of the electric vehicles. But I wouldn't be surprised if there wouldn't be a way coming along that charge cars could charge themselves. Of course, there's always solar, but you probably need more than what we can do with solar today on a small car.   Shampa Bagchi  41:34 Right, exactly. So yeah, I would say the technology problem getting it out into the world in a more cost effective way building the infrastructure, that would be the challenging part.   Michael Hingson  41:44 That's going to be a lot of what happens with software is it's all about making it more efficient, making a cost efficient and getting things out in an efficient way, isn't it?   Shampa Bagchi  41:53 Yes, yes. That's a hands on. Yeah, how how cost effective we can make it and in callings when our clients come in, that's what we tell them to, you know, we can do it very fast. We can you can build a huge, I don't know, aeroplane for you. But do you really need that? And how much budget do you have? So we have to build according to your needs and your budget, we do our best work, you know, otherwise, everything is possible.   Michael Hingson  42:17 You talk a lot both about convergehub and quarterlies. about efficiency, and the importance of that and what you do and what you're bringing to your customers.   Shampa Bagchi  42:29 Yeah, yeah, absolutely. I think efficiency is, especially you know, both in converge I've been calling so although you know, in different ways. But for convergehub, it's a matter of, I would say productivity. So it's it's how it's not just about what you can do, it's, I would say it's a matter of how well you can do it, how quickly you can do it, and what results you can get doing it. You know, that's what I would say no makes the software special. Otherwise, it's not about building a lot of features, a lot of new wonderful tools that nobody uses.   Michael Hingson  43:08 Where do you see, we talked about artificial intelligence? But where do you see that? And what other kinds of things do you see coming along in the next five or 10 years that you can look at and talk about in terms of how some of the ways we think of software, and some of the ways software will interact with our lives are going?   Shampa Bagchi  43:30 Yeah, that's that's an interesting question. I would say, software slowly will stop becoming something that you're kind of, you know, sitting at your desk or even you know, looking at it on the mobile phone, it's going to become everywhere, it's everything is going to be software. So your your and right now we do have that you know, your your TV has software, your Frasier software, but it's just going to become such that, and especially not you are going to be able to like not talk to it and redo it again, it's all there right now. But it's going to become ubiquitous, it's going to be you know, your car, your home, your, your washing machine, and every single thing that you do is going to become software, it's you, we won't call it software anymore, I think you'll just call it Life. So it's just there. And so, in terms of technology, if you will, I think voice as a technology, voice activation talking to your machines, you know, that's going to become you know, more and more important, the insights that it gives you in terms of, you know, sales software, or no customer software that we're looking at, even now, next conversion, that's our aim to, you know, bring about is that looking at your past data or whatever work that you're doing, it's telling you a future direction, and again, that is that efficiency that you talk about the productivity you talk about so there are this hunt 100 200 things that you could do today, but which 10 that you do will bring an impact which 10 of those should you focus on to get the maximum impact the maximum out of your day, so that those kinds of insights are going to become important and are right now, again, you know, everybody's trying to do it. I wouldn't say, you know, we are where we, you know, at where we should be. But we're getting there. And those are the kinds of things that I foresee, you know, happening other than the fact that, you know, we are going to probably have humanoid kind of, you know, robots and we are going to interact with then. Yeah, who knows? So those are on the rise and coming up soon.   Michael Hingson  45:40 We should have Ray Kurzweil who talks about the singularity, the time when computers, if you will, and humans merge, and we through our brains can access all of it directly. Yes.   Shampa Bagchi  45:56 The thought interface that sometimes we don't talk about, and yet those are, I don't know, it's exciting and scary at the same time, right? Just something we can't even think about. But it's slowly creeping upon us. It's happening so slowly, probably, that we are not even noticing. But we are getting there. And we just have to figure out ways and probably even laws to deal with it.   Michael Hingson  46:20 Well, and that's going to be part of it is, is the laws and trying to definitely put a standard to it, do you. But I but it seems to me and I mentioned the senator campaign, and so on, it strikes me that those kinds of, of commercials, and that kind of discussion really represents a fear of change and a fear of what these products are really bringing to us, which shouldn't be there, but it still is.   Shampa Bagchi  46:49 Yeah, absolutely. I would totally agree on that. I think it's more about the fear of the unknown in another form. So you don't really know where this is going, which is true. I mean, it's scary. But at the same time, you cannot ignore the enormous amount of value that is adding to our lives. So I would say that the way to get through this is to you know, not really ignore it, and not to shy away from it and say, hey, you know, Tesla software is buggy, so we never go autonomous, driving way. But to kind of look at it right now and say, what standards should we set to what law should we set? What is it that we need to do to make sure all of this works out? Well, for us, it doesn't end in disaster, it works out such that, you know, rather than, you know, being seen as a flaw it it's seen as something that saves lives? Because autonomous driving ultimately will save lives? If done, right.   Michael Hingson  47:48 How do we get people to go from where they are to recognizing what you just said, which is the value of a lot of these kinds of improvements? It seems like it's an ongoing battle, but how do we get people to move past? No to? Yes, if you will? Yeah, that's   Shampa Bagchi  48:06 an interesting question. I would say the only way to do it is with education, right? So it's always the fear of unknown and education is what's going to make that unknown unknown to you. So the more we can educate people, the more we kind of bring it a little more to the masses. And say that, you know, you bring it such that we can, you know, touch and feel it and see, there's really nothing to be afraid of. I think the more it works, I remember when I was in Cisco, I had, they had this big lab where they were testing out all these different things. And this was very, very initial days of, but I remember they were testing out things like technology, like you could order milk, you could ask your refrigerator to order milk for you. You know, you could turn on the oven while you're driving home, in your car, you could switch on your oven. At that time, that seems like Oh, my goodness, you know, what if my house burns down? Now, it doesn't seem so absurd anymore. So it's just a matter of education, how much we have accepted it. And it's a matter of time and education. I think it's a factor of both of them.   Michael Hingson  49:17 Yeah, and how we can get people educated more quickly, to be more adventurous. And that's what it really is, right? You You came over from India, into a pretty unknown situation. And I've experienced some of those things in my life, going from one side of the country to the other with no family and no support system and developing a whole new thing. But life is an adventure. And all too often we don't we don't think about the fact that it's an adventure and a great learning experience. And if we could get more people to view it that way, we probably would also have a lot less fear. Or at least we would be open to exploring new things even though the fear might be there. You know, again, it would be something that we can start to work to control.   Shampa Bagchi  50:03 Yeah, I would, I would totally agree with that. Because there is always risk. I mean, even in life, I mean, you don't know, you go out of the home, there is stress, you know, there's always a risk of facing. But how do you, it's just that somehow, you know, people think there is more risk in the unknown. But you know, maybe the rewards are greater in the unknown to, you just don't know that you just have to take that risk to find out what it is all about. And, to me, again, I think that's a lot about I call that the entrepreneurial mindset. And I've recently started talking about this too, because I think the entrepreneur mindset has that that thing to, you know, that spark where you can step up, you can take a little bit of risk, you can look at any challenges and say that, I'm going to solve this. It's not just about entrepreneurs, it's not that it's just in entrepreneurs, I think it's in it, regardless of what life situation isn't, whether you're in a business or whether you have are going solo or not, you know, whatever it is that you are doing right now you can bring that mindset into it. And, you know, experiment a little bit, you know, step up into it, take a little bit of risk and learn a little bit more. And that would, I think, would help, like, become a lot more interesting.   Michael Hingson  51:21 Well, tell me more about that you you are an entrepreneur, obviously by kind of any standard. But tell me more about your your thoughts about being an entrepreneur? How do we get more people to do that? How do we get more people to accept that they can possibly do the same sort of thing?   Shampa Bagchi  51:37 Yes, sure, yes, I have always been an entrepreneur, I think because I come from a family of entrepreneurs. And I always wanted to have my own company. And so it's, to me, it's more so because I love to build things, you know, whether it's a product, whether it's a company, I like to kind of you know, see the little bits coming together to form a hole, and then impacting, getting bigger than yourself. It becomes you know, initially when you're looking at it, you know, it's a vision, it's completely within you, and nobody else can see it. But slowly, when it comes out into the world, and then goes out into the world, it becomes so much so many other people get involved in this, start sharing your vision, and it becomes so much bigger than yourself. So I think it's just a matter of if somebody would like to become entrepreneur, and I think they're everyday entrepreneurs who don't necessarily have to, or have a company, they don't necessarily have to have, you know, go solo, or have their own startups raise venture capital, I think entrepreneurs are whoever are willing to step up. I think in there's this book, called I think, if I'm not mistaken, the name is daring, greatly by brainy Brown. And she said, she does really well, where you are kind of into the arena where you're willing to go into the arena, and, you know, face off your challenges. So that thought process I would think is more about becoming an entrepreneur than anything else. So if I think you are ready to take on responsibility, take ready to learn new things. That mindset is what we know people need to bring in   Michael Hingson  53:22 what excites you about going to work every day?   Shampa Bagchi  53:26 That's that's a really nice question. I think, I think what really excites me is that I have the tools to make a difference, that I can structure my day in such a way and build things that someday will probably, you know, touch somebody's life, with an especially probably will touch with somebody's life, even when I don't know about it. So that's why I often love hearing about, you know, convergehub from users, when users reach out to me saying, yeah, how do I solve this problem? Or, Hey, I used it, you know, in this particular case, and it worked for even saying that, you know, if you just improve this thing a little bit, it will help do this. So it's just kind of know people have taken something that we envision visualized, which was this small and they're using it in their own doing their own thing, which is completely different from what we visualized, and it still works. So that's really exciting. You know, how I'm able to touch people's life and improve their livelihood in whatever little bit   Michael Hingson  54:30 you know, a lot of people say, well, it's all about making money, we got to be more very successful because we make more money, but I'm not hearing you say that's the biggest priority. It's really   Shampa Bagchi  54:40 never been that really it's never been that because if so I would probably go out I'm here in the Silicon Valley. We started our company pretty early in the day would have gone out raised a lot of capital, you know, gone IDI pure road and not done that and made a lot of money, but it's a little more are in a complex than that to me. So I would like to go in my own pace, do my own thing and make my own mark in the   Michael Hingson  55:06 world view. You mentioned Brene Brown and her book, have you thought about writing a book?   Shampa Bagchi  55:11 I actually have Yes. I have thought about it. A lot of times haven't found the time yet. But someday, I'm going to read a book,   Michael Hingson  55:23 you have a lot of insights that I think people would like to hear, and which is one of the reasons I thought it would be great to have you on this podcast. But you do have a lot of insights that I think would inspire people and motivate people and the lessons that you have learned. And the things that you teach to your employees and your customers are all valuable insights that I would think, would make a fascinating book. And of course, I have written two books and working on our third now talking about fear. But I am a firm believer in something that you said, which is it's all about telling stories to. So it isn't just preaching at people, it's it's using stories to illustrate what you talked about. And you've done, you've told a number of those stories in what we're doing here, which I think is great, because it really shows in real life examples. What's happening.   Shampa Bagchi  56:20 Great. Yeah, thank you, Michael, I really, really appreciated that. And I'm so thankful you said that, because it's been on my mind for a long time, I would love to share my experiences in a book, I love writing to. So it's one of my passions. And if I find the time when I find the time, I don't have a blog, though. So I write very short blogs, whatever I can manage. But someday, hopefully, I'll be able to sit down and you know, you narrate these experiences,   Michael Hingson  56:48 and do you do videos or any other ways of communicating with people outside?   Shampa Bagchi  56:53 I recently started doing that. I actually yesterday, I put out my first video on LinkedIn. And I'm planning to do that and more and more, because what I'm seeing is, that's another really another different medium for somebody who was not that fond of reading to still be able to go out and, you know, put your ideas forward in front of that person. So I intend to do that more and more.   Michael Hingson  57:17 What was your first video about   Shampa Bagchi  57:18 entrepreneurship? Course I was actually talking about what it means to be an entrepreneur, believe it or not. So that was one topic very fresh. On my mind, when I started talking about Italy, well, it   Michael Hingson  57:29 makes makes perfect sense. And again, I think is you work toward a book, and you can always get people to, to help do some of the writing. But just just to save time, or free up some of yours. But in the books that I've written, I've worked with two writers and I'm working with the third professional writer in the book that we're writing now. And the working title of it is a guide dogs Guide to Being brave, because we're talking about controlling fear, which is of course what happened to me on September 11, being in the World Trade Center in escaping, it was all about for me be knowing in advance what to do in the case of an emergency and being as prepared as one could be, which kept the fear away. I was certainly always concerned about what might happen while we were going down the stairs because there was fire above us. And we had no idea it was an airplane or anything that hit the building at the time. None of us did. It wasn't a blindness issue. But clearly something was very seriously wrong. And at the same time, the preparation that I had made in advance was very helpful until we finally decided during the pandemic to write about that. And so I'm working with a writer Carrie, why can't and we're putting the book together. And what I find is that she does a lot of the writing, I do a lot of the writing. But I also because we want to put it in my story, even then take what she writes in and tweak it some, but it's still a whole lot less time than if if I did it all. So it's another another way to go. But for me, it does help to get the message out there to put it in a book form. And people have appreciated what we've written so far. So I guess it's a good thing.   Shampa Bagchi  59:15 Yeah, yeah, absolutely. And your story is is so so inspiring. I read about it and your website, I do plan to get your book and read all about it, you know, in more detail. But you know what you went through and how not with your dog, it's very, very inspiring story.   Michael Hingson  59:33 Yeah, what people often miss is that it's a team effort. The dog has a job to do, and I have a job to do that. The dog doesn't leave the dog guides and there's a big distinct difference between those two. But thunder dog is the title of the book and it it is out there and I think that it helps to teach people a lot about what blindness is really like as opposed to what we think it is. And it's the usual myth that people have Ms. conceptions, whether it's about blindness or technology or whatever, it is all about education and getting people to, to move forward and recognize that maybe we have the wrong idea about what this is about.   Shampa Bagchi  1:00:11 Yeah, I absolutely am going to read your book. And do you know, when your new book is coming out? Did you set a date yet?   Michael Hingson  1:00:20 The tentative date is, by the time all is done, we get it edited, and everything else is going to it's, it's a while away as a way yet, probably in the first, well, probably in the second quarter of 2024. So it's not going to be soon.   Shampa Bagchi  1:00:36 It's been a while. Yeah, it's going to be a while, but I'm looking forward to it already. Definitely going to read that one too.   Michael Hingson  1:00:42 Well, we were blessed to get a contract signed with a publisher. And so we're working with their timeframe. We've we've talked about when to publish it, and why to publish it then. So I think it'll be kind of fun. But we at this point where there's thunder dog and running with Roselle, so definitely get them and running Anthony center dog especially is also available in audio format, which is an easy way to get it if you do much driving here. Yeah, sure. Yeah, in an autonomous vehicle.   Shampa Bagchi  1:01:10 I was very good for that. But I just love reading. So I'm definitely going to get that and your book was bestseller too, right?   Michael Hingson  1:01:19 Yeah, it was the number one New York Times bestseller. Again, we were very blessed with that. So that's impressive. We like that. Well, Shamp, I'm going to let you go back to doing some of the creative things that you do. We've been talking for an hour, and it's been fun. already. I know. Isn't that fun? You are welcome. You are welcome to come back. Anytime. If you want to talk further. I would love to do that. And definitely I want to stay in touch. I love what you had to say about artificial intelligence and so on. And I'm glad that you did check out excessively we talked about that very briefly briefly. It's it's also a bleeding edge type of technology.   Shampa Bagchi  1:01:57 It is it is yes, it was I was very impressed with it. I did take a look at it. And I look forward to talking to them again. Well, we'll   Michael Hingson  1:02:04 help facilitate that and, and anytime that we can be of help them. And if you want to talk more to folks here, don't hesitate. We can even use some of these podcasts to help with your book.   Shampa Bagchi  1:02:17 Oh, yeah, that would be wonderful. Thank you so much, Michael, thank you for that idea. It's been a pleasure talking to you. It's been a lot of fun.   Michael Hingson  1:02:24 I've enjoyed it very much. And I hope all of you who are listening, have enjoyed it. Wherever you are, I hope that you enjoyed the last hour. If you would like I want to hear from you. But before I give you my contact information Shampo how can people find you and maybe learn more about what you're doing and about convergehub and so on?   Shampa Bagchi  1:02:44 Yeah, I have a bl

Introduction to Arun Patnaik(00:30 )Arun has an amazing story — right now he's a vice president in Oracle. And he's working on some really exciting projects, which we will talk about. But he also has a very interesting story similar to mine, he came from India, from a remote village, and now he's managing a team of about 250. So let's talk to him. Let's understand his journey, what he has learned and what lessons he can share with usHighlights(5:19) So it seems like the innate talent you had was showing up early… getting that scholarship. And I think, as you said, the foundational learnings that we get from our parents, and in early childhood, really shape our life. And the last thing I take away from this is, as you said — Sybase approach you twice — if something is meant to be, it generally happens. (33:53) Mentoring for me has been… asking hard questions to myself. The key is to seek out mentors, depending on wherever you are, find somebody who has been through that or who has some idea about it. And hopefully, they can point you to look at things in a certain manner. Mentoring is an enriching experience. Because you have only one life — and if you wanted to learn everything you could learn only from your experience… that would be limited. Arun continues to talk about mentoring — so mentoring also gives you exposure to problems others are facing, and how they're overcoming them…Support the show

This week Rachael and Eric discuss the recently published "Defending Ukraine: Early Lessons from the Cyber War" report from Microsoft and the accompanying blog post by Microsoft President and Vice Chair Brad Smith. They share insights and raise lingering questions on the report's findings and the five conclusions Microsoft framed from the war's first four months. They also briefly share insights from the June 2022 cyberdefense research report "The IT Army of Ukraine" from Stefan Soesanto of the Center for Security Studies in Zurich. So much to unpack in this week's episode! There will definitely be follow-on episodes with key players from these reports that you won't want to miss! Host Rachael Lyon Rachael Lyon brings her journalistic curiosity and more than 20 years in technology working with global industry leaders and innovative start-ups to dig into today's cyber news and trends impacting us all. Co-host Eric Trexler Eric Trexler is Vice President of Sales, Global Governments, Forcepoint. Eric has more than 21 years of experience in the technology industry with both the public and private sectors including the DoD, Civilian, and Intelligence components. Prior to joining Forcepoint, Eric was the Executive Director for Civilian and National Security Programs at McAfee, formerly Intel Security. Prior to joining McAfee in 2010, he managed multi-million dollar accounts at Salesforce.com, EMC Corporation and Sybase, Inc. Eric served as an Airborne Ranger with the United States Army for four years, specializing in communications. He holds a bachelor's degree in marketing and an MBA with a concentration in strategy, both from the University of Maryland at College Park. LinkedIn https://www.linkedin.com/in/eric-trexler-8b6b39/ https://www.linkedin.com/in/rachaellyon/ For links and resources discussed in this episode, please visit our show notes at https://www.forcepoint.com/govpodcast/e187

This episode with Patrick Lencioni is a great segue from the article released by Wes Cochrane last week titled, "Does Your Team Suck at Workplace Conflict?"  Read that article here.   Patrick Lencioni is one of the founders and president of The Table Group, a firm dedicated to providing organizations with ideas, products and services that improve teamwork, clarity and employee engagement. Patrick's passion for organizations and teams is reflected in his writing, speaking and executive consulting. He is the author of 11 best-selling books, which have sold over 6 million copies and been translated more than 30 languages. His capstone book, The Advantage, is the pre-eminent source on organizational health. After sixteen years in print, his classic book, The Five Dysfunctions of a Team, remains a weekly fixture on national best-seller lists. Released in 2016, The Ideal Team Player is a much-anticipated follow-up to his team book and also a Wall Street Journal best-seller. The wide-spread appeal of Lencioni's leadership models have yielded a diverse base of speaking and consulting clients, including a mix of Fortune 500 companies, professional sports organizations, the military, non-profits, schools and churches. Pat addresses thousands of leaders each year at world-class organizations and national conferences. Consistently the top rated keynote speaker at major events, Pat shares his insights and inspires his audiences through his accessibility, humor and story-telling. The Wall Street Journal said he is "one of the most in-demand business speakers." Named in Fortune magazine as one of the ‘ten new gurus you should know,' Pat and his work have been featured in USA TODAY, Bloomberg Businessweek, and Harvard Business Review, to name a few. Prior to founding his firm, he worked as a corporate executive for Sybase, Oracle and Bain & Company. Pat lives in the San Francisco Bay Area with his wife and four sons. Pat is really excited about a brand new concept he and his team are launching this week called the 6 Types of Working Genius. This is an incredible tool that helps you and I identify what we are really good at and those parts of work that make us most frustrated.  Pat had me take the assessment and we discuss my results and his results.  We also dive into the organizational health movement, how to create what he calls “vulnerability-based trust” on your team, why the right kind of conflict on a team is a sign of health, and much more.  To do The 6 Types of Working Genius Assessment, click here

We went On Call with Eric Barbier, the CEO and founder of TripleA, B2B crypto payments solutions company headquartered out of Singapore, that helps businesses globally increase their revenue by enabling crypto payments and payouts. In this jampacked call, we do not only talk about crypto and TripleA's work in pioneering business payments use cases, but also Eric's entrepreneurial journey, being a serial fintech founder scaling companies amidst challenging market conditions like the turn of the millennium dotcom boom and crash, then the global financial crisis, as well as driving payments adoption and use cases from web2 to now web3 with TripleA. Eric and TripleA are also the first investee of Insignia Ventures Partners' Moonshot Fellowship (see full press release), bringing together a network and community of web3 founders and talent building important infrastructures and laying the foundations for the still-nascent web3 ecosystem. Transcript Timestamps (00:23) Paulo introduces TripleA and Eric; (02:26) The Entrepreneurial Pioneer Journey from Mobile Messaging to Mobile Payments to Crypto Payments for Business; (06:16) Building for Crypto's Mainstream Adoption through B2B Payments Solutions; (11:12) Advantages of Building Crypto Solutions in Singapore; (14:51) Assorted Topics: Un-Learnings from Web2, Starting Companies in Fundraising Winters, Local Stablecoins, Bridging Web2 Fintechs to Web3; (21:25) Future of Global Crypto Payments; (23:41) Rapid Fire Round; About our guest TripleA is founded by Eric Barbier, a repeat FinTech entrepreneur with a proven track record of building successful payments companies. He co-founded Mobile 365 back in 1999, a mobile messaging hub that reached a subscriber base of over 400 million. It was acquired by Sybase (now SAP) for $425M. He then founded TransferTo (now Thunes) in 2006 on the idea that transferring money should be as easy as sending a text message. Today, Thunes has raised over $60M and is now the largest payment network connected to mobile wallets. With partners like Paypal and M-Pesa in its network, Thunes supports 60+ currencies, enables payments to 110+ countries, and helps businesses accept 285+ payment methods. He is also an investor and board member in global fintech companies, including the first digital bank in Saudi Arabia. Music: Energetic and Upbeat Rock Background Music For Videos and Workouts The content of this podcast is for informational purposes only, should not be taken as legal, tax, or business advice or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any Insignia Ventures fund.

Catriona Walkerden is the Vice President of Global Marketing at Logicalis, a leading digital transformation enabler and Cloud Managed Services Provider. Catriona has had an impressive career in technology that spans over two decades, serving innovative IT brands like Cisco, Oracle, Sybase, Whispir, Optus and now Logicalis.She is also passionate about elevating women in IT to reach their potential.We discuss:How she structures her marketing team with the right mix of skills The most significant changes in tech and diversityHow the role of the B2B marketing leader will changeTackling marketing challenges at various growth stagesMentioned in this episode:Brought to you by CMO Crowd and The Marketing PracticeFind out more at cmocrowd.com

This week co-hosts Eric and Rachael are coming to you live from Cabo San Lucas! They cover hot topics including CyberWire's new CISA Cybersecurity alerts, the impact of ransomware on a 157 year-old university in Illinois, Colonial Pipeline's nearly $1M proposed fine by the Department of Transportation Pipeline and Hazardous Materials Safety Administration and the recent surge in tractor hacking! Rachael Lyon Rachael Lyon brings her journalistic curiosity and more than 20 years in technology working with global industry leaders and innovative start-ups to dig into today's cyber news and trends impacting us all. Eric Trexler Eric Trexler is Vice President of Sales, Global Governments, Forcepoint. Eric has more than 21 years of experience in the technology industry with both the public and private sectors including the DoD, Civilian, and Intelligence components. Prior to joining Forcepoint, Eric was the Executive Director for Civilian and National Security Programs at McAfee, formerly Intel Security. Prior to joining McAfee in 2010, he managed multi-million dollar accounts at Salesforce.com, EMC Corporation and Sybase, Inc. Eric served as an Airborne Ranger with the United States Army for four years, specializing in communications. He holds a bachelor's degree in marketing and an MBA with a concentration in strategy, both from the University of Maryland at College Park. For links and resources discussed in this episode, please visit our show notes at https://www.forcepoint.com/govpodcast/e183

Is positioning for your product or for the brand? Well, it's both! And the better your positioning, the better you sell. But how do we go about this? We spoke to the the leading expert in the space, April Dunford to unpack her secrets to success for you. More About April (from April) I spent the first 25 years of my career as a startup executive, running marketing, product, and sales teams. I led teams at seven successful B2B technology startups. Most of those startups were acquired (DataMirror to IBM, Janna Systems to Siebel Systems, then SAP, Watcom to Sybase via Powersoft, to name a few), and I ran big teams at IBM, Siebel, Sybase, and others. The total of those acquisitions is more than two billion dollars. Across that journey, I positioned, re-positioned, and launched 16 products.  I have a deep curiosity about what makes the difference between a winning product and a loser. Developing a systematic way of positioning technology products and companies has become my life's work. As a consultant, I have had the privilege of working with more than 100 companies, allowing me to go even deeper and broaden my positioning expertise. The bulk of my work is with early and growth-stage startups. Companies where the stakes are high - and weak positioning can mean the difference between success or failure. I also work with large global companies, helping them develop deeper positioning expertise in their product and marketing teams.  My book, Obviously Awesome, captures my ideas about positioning and a methodology for doing it that any startup can follow. It's become a best-seller and popular among entrepreneurs, product, and marketing folk. I studied Engineering in University, and if you had told me then that someday I would be an author, I would have said you were nuts. It turns out my grade 6 English teacher was wrong about the importance of grammar.  I'm at the stage of my career where I'm trying to give back as much as I can. I am a mentor and advisor to dozens of startups and folks that work in them. I am an enthusiastic board member at a handful of startups.  I live in Toronto, Canada. I have kids, a small dog, and a cabin in the woods. Want More? Visit us at https://changecreator.com/ (https://changecreator.com) Ready to Grow Your Brand Authority and Revenues? Book a call to chat with Adam at https://studio.changecreator.com/ (https://studio.changecreator.com)

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.

Linda Hand brings 35 years of experience to her role as CEO of Prealize Health, with an emphasis in organizational leadership, product development, solutions delivery and go-to-market strategies across a diverse portfolio of industries. Before joining Prealize, Linda led the Clinical Trial Optimization Solutions division at IQVIA, where she was responsible for creating and delivering a suite of innovative clinical technology products, fueled by predictive analytics and machine learning algorithms, to drug development organizations worldwide.Linda is a past President and CEO of the San Francisco-based DecisionView, the leading provider of clinical trial enrollment optimization solutions. She also ran product development and delivery at a number of leading software companies, including DigitalThink, Hyperion, Arbor Software and Sybase.Linda holds a BA in Computer Science from the University of California, Berkeley, and completed the Haas School of Business Executive Program.John Marchica, CEO, Darwin Research GroupJohn Marchica is a veteran health care strategist and CEO of Darwin Research Group. He is leading ongoing, in-depth research initiatives on integrated health systems, accountable care organizations, and value-based care models. He is a faculty associate in the W.P. Carey School of Business and the graduate College of Health Solutions at Arizona State University.John did his undergraduate work in economics at Knox College, has an MBA and M.A. in public policy from the University of Chicago, and completed his Ph.D. coursework at The Dartmouth Institute. He is an active member of the American College of Healthcare Executives and is pursuing certification as a Fellow.About Darwin Research GroupDarwin Research Group Inc. provides advanced market intelligence and in-depth customer insights to health care executives, with a strategic focus on health care delivery systems and the global shift toward value-based care. Darwin's client list includes forward-thinking biopharmaceutical and medical device companies, as well as health care providers, private equity, and venture capital firms. The company was founded in 2010 as Darwin Advisory Partners, LLC and is headquartered in Scottsdale, Ariz. with a satellite office in Princeton, N.J.

Chris got a bike. Specifically, he bought a bike to use in a triathlon he signed up to participate in. Now he needs to name the bike, and speaking of naming things, a more technical topic that he talks about is the Crispy Brussels Snack Hour. Steph talks about Rescue Rails projects and increasing developer acceleration. They answer a listener question asking, "Why do so many developers and agencies, thoughtbot included, replace the default test suite in Rails with RSpec?" This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Translate frustrations into professional corporate (https://twitter.com/MeanestTA/status/1509936432625897474) Learn Hotwire by Building a Forum (https://twitter.com/afomera/status/1512287468078264322) parallel_tests (https://github.com/grosser/parallel_tests) parallelsplittest (https://github.com/grosser/parallel_split_test) This episode is brought to you by Studio 3T (https://studio3t.com/free). Try Studio 3T's full suite of features for 30 days, no payment details needed. Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: Oh, but I recently learned that Robert Downey Jr. in the Marvel movies he's snacking a lot, maybe not Iron Man, but something...oh no, he's stacking a lot. And I'd read that he was snacking a lot on set, and so they just built it in to where like, sure, you can snack as your character while you're doing stuff. CHRIS: [laughs] STEPH: And I think that's so cool because I find that I am eating every time I show up to record with you. So I would like the same special star treatment as Robert Downey Jr., [laughs] and I just get to eat during each Bike Shed. [laughs] CHRIS: All right. [chuckles] My understanding is also that he was wildly the highest paid of all the actors, so I think that should also come along with this. STEPH: [laughs] CHRIS: Yeah, there's a lot that we can sort of layer on here, but it makes sense to me, and I'm fully on board. STEPH: You're an excellent agent. Thank you for fighting for my higher pay. [laughter] CHRIS: You are welcome. STEPH: What a good co-host you are. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. One of these days, I'm going to say, "I'm Chris Toomey," and then I'm just going to see how you roll with it, although now I'm ruining it, I should have just gone for it. [laughs] CHRIS: Nothing can prepare me for this despite the fact that you're telling me in this moment. In that future moment when you do it, I will still be completely knocked out of whack. Just like for anyone out there listening, the thing that Steph would normally have said instead of what [laughs] she just said was, "What's new in your world?" STEPH: [laughs] CHRIS: And I contractually require that that is the only way she starts this question to me because I get completely lost. She's like, "How are you doing?" I just overthink it, and I get lost, and then we end up in a place like this where I'm just rambling. STEPH: Every podcast contract you have from here on out must begin with hey, Chris, what's new in your world? [laughs] I will still get to that question. I just also had to tell you my future joke. I'm going to play that. Hopefully, you'll forget, and one day I will resurface. CHRIS: I can pretty much promise you that I'm going to forget it. [laughter] STEPH: Excellent. Well, to make sure I stick within the Chris Toomey contract guidelines, hey, Chris, what's new in your world? CHRIS: What's new in my world? Now I just want to spend a lot of time putting together my rider. There can be no brown M&M's in the bowl. No eye contact, please. And I can only be addressed with this one question which is, to be clear, very not true, Steph. And I always record with a video because we actually like to have human faces attached to things. Anyway, I'm going to tighten this all up. When we get to the technical segment of my world, I'm going to tell you about Crispy Brussels Snack Hour, so just throwing that out there as an idea. But before we do that, I'm going to share a fun little thing which is I bought a bike, which is exciting. It's not that exciting. People have bikes. This is exciting for me. But the associated thing that is more exciting/a little terrifying is I'm going to try and run a triathlon. I'm going to try and run, swim, and bike a triathlon as they go, specifically a sprint triathlon for anyone out there that's listening and thinking, oh wow, that sounds like a thing. The sprint is the shortest of the distances, so that's what I'm going to go for. But yeah, that's a thing that I'm thinking about in my world now. STEPH: I know next to nothing about triathlons. So what is a sprint in terms of like, what is the shortest? What does that mean? CHRIS: I think there actually maybe even shorter distances but of the common, there's sprint, Olympic. I want to say half Ironman, and then Ironman are the sequence. And an Ironman, as far as I understand it, I think it's a full marathon. It's like a century bike ride or something like that. It's an astronomical amount of everything. Whereas the sprint triathlon being the shortest, I think it's a 3.6-mile run, so a little over a 5K run, a 10-mile bike ride, and a quarter-mile swim, I want to say, something like that. But they're each scaled down to the rough equivalent of a 5K but in each of the different events. So you swim, and then you bike, and then you run. And so I'm going to try that, or at least I'm going to try to try. It's in September, and now is not September. So I have a lot of time between now and then to do some swimming, which I haven't done...like, I've swum but not in a serious way, not in an intentional way. So I got to figure out if I still know how to swim, probably get better at biking, and do a little bit of running, and it's going to be great. It's going to be a lot of fun. I'm super excited about it. Only a little terrified. STEPH: I think this is where as your co-host coach, which you have not asked me to be, where I would say something about there is no try, to mimic Yoda. [laughs] CHRIS: Yep, yep. Yep. Do or do not. Sprint or sprint not. There is no trying. Oh, were you making a try pun there? STEPH: I didn't go that far, but you just brought it home. I see where you're going. [laughs] CHRIS: This is pretty much what I do professionally is I just take words, and I roll them around until I find something else to do with them. So glad that we got there together. STEPH: Well, I'm really excited to hear about this. I don't know anyone that's trained for a triathlon. I think that's true. Yeah, I don't think I know anyone that's trained for a triathlon. So I'm curious to hear about how that goes because that sounds intense, friend. CHRIS: I think so. None of the individual segments sound that bad but stitching them all together, and I think the transitions are some of the tricky parts there. So yeah, it'll be fun. It's something I find...I used to never run; that was the thing. Like, deeply true in my head was that I'm not a runner. This is just a true fact about me. And then I ran a 5K one year for...it was like a holiday 5K fun run with friends. And every bit of the training leading up to it was awful. I did Couch to 5K. I hated it. My story in my head of I'm not a runner was proven with every single training run. Man, did I hate it. And then something magical happened on the day that I actually ran the race, and it was fun. And I was out there, and there was the energy of being in this group of people. But it was competitive and not competitive in this really interesting way. And then it ended, and we were just hanging out in a parking lot, and they gave us beer. And I was like, well, this is actually delightful. Maybe I actually like this thing. And so I've run a bunch of different races. And I've found that having a race to train for, and by train, I just mean some structured attempt at running, has been really enjoyable and useful for me. So yeah, this is just ratcheting that up a tiny bit. I've done a couple of half marathons is the high watermark so far. It's a good distance. But I don't know that a full marathon makes sense; that's a real commitment. And I'm looking to move laterally rather than just keep getting more complex in my running. So we're trying the shortest possible triathlon that I know of. STEPH: I am such a believer that exercise should be fun, so I love that. Like, I'm not a runner, but then you get around people, and it's exciting. And then there's that motivation, and then there's a fun ending with beers that totally jives with me. Because sure, I can go to the gym; I can lift weights, I can make myself exercise. There's some fun to it. But I strongly prefer anything that's more of like a sport or group exercise; that's just so much more fun. Well, super cool. Well, I'm excited. I would ask you all the details about your bike, but I know nothing. Do you want to share details about your bike? There may be other people that are interested. CHRIS: Oh yeah, my bike. I went to the bike store, and I said, "Could I have a bike, please?" And then they toured me around and showed me all the fancy...they were like, "This is our most modest entry-level bike." And then they kept walking around and showing me fancier bikes. And I was like, "Can we go back to that first one? That one seemed great." STEPH: [laughs] CHRIS: Because it got all of the checkboxes I was looking for, which is basically it's a bike. So actually, the specifics on it are it's a hybrid bike, so like a mix between road, and I don't even know the other road bikes I know of, and maybe it's trail. But I don't think it's meant for going on the trail. But for me, it'll be fine for what I'm trying to do as far as I understand it. It's technically a fitness hybrid, which I was like, oh, fancy. It's a fitness bike; look at me go. But it was basically just like, I would like a bike. General-purpose hybrid seems like the thing that makes sense. So I got a hybrid bike. And that's where I'm at. Oh, and I got a helmet because that seems like a smart move. STEPH: Nice. Yeah, the bike I own is also one of those hybrids where it's like…because when I moved to Boston...and lots of people have the road bikes, but their tires are just so skinny; it made me nervous. And so I saw one of the hybrid bikes, and I was like, that one. That looks a little more steady and secure, so I went with that one even though it's heavier. Do you have a name for your bike? Are you going to think of a name for your bike? CHRIS: I didn't, and I wasn't planning on it. But now that you've incepted me with this idea that I have to name my bike, of course, I have to name my bike. I'm going to need a couple of weeks to figure it out, though. We're going to have to get to know each other. And you know, something will become true in the universe for me to answer that question. But as of so far, no, I do not have a name for the bike. STEPH: Cool. I'll check back in. Yeah, it takes time to find that name. I feel you. CHRIS: [laughs] Yeah, don't make up a name. I have to find what's already true and then just say it out loud. Speaking of naming things and perhaps doing so in a frivolous way, as I mentioned earlier, the more technical topic that I want to talk about, oddly, is called Crispy Brussels Snack Hour. [laughs] So, within our dev team, we have started to collect together different things that don't quite belong on the product board, or at least they're a little more confusing. They're much more technical. In a lot of cases, they are...our form handling is a little rough. And it's the sort of thing that comes up a lot in pull requests where we'll say, "I feel like this could be improved." And we're like, "Yeah, but not in this pull request." And so then it's what do you do with that? Do you put a tech debt card in the product board? You and I have talked about tech debt cards plenty of times, and it's a murky topic. But we're trying within the team to make space and a way and a little bit of process around how do we think about these sorts of things? What are the pain points as a developer is working on the system? So to be clear, this isn't there is a bug because bugs we should just fix; that's my strong feeling, or we should prioritize them relative to the rest of the work. But this is a lower level. This is as a developer; I'm specifically feeling this sort of pain. And so we decided we should have a Trello board for it. And they were like, "Oh, what should we name the Trello board?" [laughs] And I decided in this moment I was like, "You know, if we're being honest, I've named everything very boring, very straight up the middle. We don't even have that many things to name. So we have zero frivolous names within our team. I think this is our opportunity. We should go with a frivolous name. Anybody have any ideas?" And someone had worked on a team previously where maybe it was a microservice or something like that was called crispy Brussels, like, crispy Brussels sprouts but just crispy Brussels. And so I was like, "Sure, something like that. That sounds great." And then they ended up naming it that which was funny, and fun, and playful in and of itself. But then we were like, "Oh, we should have a time to get together and discuss this." So we're now exploring how regularly we're going to do it. But we were like, let's have a meeting that is the dev team getting together to review that board. And we were like, "What do we call the meeting?" And so we went around a little bit, but we ended with the Crispy Brussels Snack Hour. STEPH: That's delightful. I love the idea of onboarding new people, and they just see on their calendar it's Crispy Brussels Snack Hour, come on down. [laughs] CHRIS: It's also got an emoji Brussel sprout and an emoji TV on either side of the words Crispy Brussels Snack Hour. So it's really just a fantastic little bit of frivolity in our calendars. STEPH: [laughs] That's delightful. How's that going? I don't think we've tried something like that explicitly in terms of, like you said, there are discussions we want to have, but they're not in the sprint. They're not tech debt cards that we want to create because, like you said, we've had conversations. So yeah, I'm curious how that's working for you. CHRIS: Well, so we've only had the one so far; it went quite well. We had a handful of different discussions. We were able to relatively prioritize this type of work within that. But one of the other things that we did was we had a conversation about this process, about this meeting, and the board. And whatnot. So we identified a couple of rules of the road or how we want to approach this that I think will hopefully be useful in trying to constrain this work because it's very easy to just like; nothing's ever perfect. And so this could very easily be a dumping ground for half-formed ideas that sound good but aren't necessarily worth the continued effort, that sort of thing. So the agenda for the meeting as described right now is async between meetings. Any of us can add new cards, ideally stated as problems and not solutions. So our form handling could use improvement. And then in the card, you can maybe make a suggestion of I think we could use this library or something like that. But rather than saying use this library or move to this library, we frame in terms of the problem, not necessarily the solution. And then, at the start of the meeting, any individual can champion a card so they can say, "Here's the thing that I really want everyone to know about that I've been feeling a lot of pain on." So it's a way for individuals who have added things to this to add a little bit more detail. Then using Trello as voting functionality, we each get a couple of votes, and we get to sprinkle them across different cards, and then using that now allows us collectively to prioritize based on those votes. And so the things that get voted up to the top we talk about; we prioritize some amount of work coming into the sprint. If it's actually going to turn into work, then it'll go onto the product board because ideally, it's moved from problem space to more of solution space even if the solution, the work to be done is do a spike on XYZ library or approach to form handling or whatever it is. But so ideally, it then moves on to the other board. The other thing that I felt was important is it's very easy for this to be a dumping ground for ideas. So my suggestion is at the end of the meeting, we sort by date, and we prune the oldest things. So it's like, if it's still hanging around and we haven't done it yet, and it's not getting voted up, then yes, we might feel some pain but not enough. It's not earning its place on this board. So that's my hope is we're weeding the Brussel sprouts garden that we have at the end of the meeting. That's roughly what we have now. We really only had the one, so that idea of pruning will probably come in later on. And it may be that this doesn't work out at all, and this ends up being tech debt cards that get stale and don't capture the truth. But I'm hopeful because there's definitely...there's a conversation to be had here. It's just whether or not we can make sure that conversation is useful and capturing the right amount of context and at the right points in time and all of that. STEPH: Yeah, I like it. I like the whole process you outlined. You know what it made me think of? It sounds like a technical retro, not that retros can't be technical; we bring up technical stuff all the time. But this one sounds like there was more technical discussion that was still looking for space to bring up. So the way that you mentioned that people add their thoughts, that it can be done async, and then you vote up, and then as things get stale, you remove them and focus on the things that the team voted for, that's really cool. I've never thought of having just a technical-specific retro. CHRIS: Yeah, definitely informed by retro. But again, just that slight honing the specific focus of this is just the dev team chatting about deeply dev-y things and making a little bit of space for that. I think the difficulty will be does this encourage us to work on this stuff too much? And that's the counterbalance that we have to have because this work can be critically important. But it can also be a distraction from features that we got to ship or bugs that are in the platform or other things like that. So that balancing act is something that I'm keeping in mind, but thus far, the way we structured it, I'm hopeful. And I'm interested in exploring it more, so we'll see where we get to. And I'll certainly report back as we refine the Crispy Brussels Snack Hour over time. STEPH: I feel like the opposite is true as well, where you have these types of concerns and things that you want to bring up. And even if they're on the board, once you get to sprint planning, there's a lot of context and conversation there that maybe the whole team doesn't have. It doesn't feel like the right moment to dive into this because you're trying to plan a new sprint. So then that stuff gets bumped down to the bottom or just never really discussed, or it gets archived. So I feel like the opposite is totally true, too, where you have this stuff, but then it never gets talked about because sprint planning is not the right place. So yeah, I'm really intrigued to see how that balance works out for y'all as well. CHRIS: Yeah, I think it's an exciting time, and we'll see where it goes. But like I said, I'm hopeful on it. But yeah, bikes, triathlons, and crispy Brussels, that's my world. Mid-roll Ad: Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: I have a couple of fun things that I want to share and then something that's a little more in the techie space. The first one is there's a delightful Twitter thread that caught my attention recently that I just want to share; totally not tech-related. But this person shared a thread talking about how they help everyone on their team who's older than they are, making sure that the slang that they're using is correct in its context. And so they provided some funny examples. And then, in return, they also will translate this person's frustrations into professional corporate-speak, and it's such a good thread. So if you need a good laugh, I will make sure to include a link in the show notes. The slang is really funny, but it's actually the translation of frustrations into professional corporate-speak that that's the part that resonated with me. That was really good. [laughs] CHRIS: You shared this with me outside of this conversation, and I've read through them. Listeners out there, do not sleep on this. I highly suggest reading through this thread because it is fantastic. STEPH: The other thing that I saw is Andrea Fomera, who is a Rails developer and creates a fair amount of content...I haven't been through some of that content, but I know there's content around Rails. And specifically, there is a newer course called Learn Hotwire by Building a Forum. And she has made this totally free, and I just think that is so cool. And she shared that on Twitter, so I'll be sure to include a link in that to the show notes because Hotwire is something I haven't used yet. And so I saw this free course, and I think it would be fun to dabble and go through the course. And I know there are some other people at thoughtbot that have used it and seem really happy with it or interested in using it as well. Is that something that you've used? CHRIS: I have not. I skipped over Hotwire in my adventures. I'd found Inertia and was quite happy with that. And then, in that way that, I sometimes limit the amount of things that I'm allowed to explore on the internet in hopes of actually getting some work done; I have not spent much time. But enough folks that I deeply respect are very excited about Hotwire that it remains in the like; I would love to have an afternoon just to poke around with that. So I may take a look at this, although I don't know, I'm probably still in my moratorium. I'm not allowed to look at new frameworks for a little while time period. But I hear great things. STEPH: That's fair. That's also what I've heard. I've heard great things. So yeah, I just figured I would share that in case anybody else is interested in looking for a course that they could take and also dabble at Hotwire. The other thing that's on my mind is more the type of projects that I'm really getting a lot of joy from. Because I've known about myself for a while that greenfield projects are nifty, but they're not my thing. They're not the thing that brings me a lot of joy. It's just kind of nice. You got your own space, and you're building from the ground up, cool, cool, cool. But this one, I found that the projects that I'm really starting to gravitate towards are what I've heard someone else call Rails Rescue projects. So those are the projects where they have been around for a while, or they've just been built in a way that the data modeling structure makes it really hard to implement new features. Maybe there's a lack of test coverage that makes it really risky to ship new work or to make changes. There are lots of bug reports and errors that the team is fighting with. So then that type of work comes down to where you're trying to either increase stability for the application and for users and/or you're looking to increase developer acceleration. And I really, really liked those projects. That's the type of project that I've been a part of for...I think my last couple of clients have been in that way. I don't know that they would describe it that way, that it's a Rails Rescue project. But if I can see that opportunity where I see there's a stability issue or developers are feeling a lot of pain in one area, then that's the portion of the application, the portion of the team that I'm going to gravitate towards. Or like the current work that I'm doing where we're really focused on testing and making some improvements there or reducing that pain that the team is feeling around how long CI takes to run or the flakiness because then you're having to re-verify your CI runs. I like that work. It's a bit slow and frustrating, so it does seem to require a patient person. You also have to have lots of metrics that are guiding you because you can have a lot of assumptions around I'm going to make this improvement, but it's going to take effort to get there. And it'd be great if I can validate that effort upfront. So I feel like a lot of my time is spent more around metrics, and data, and excel sheets than necessarily coding. I don't know if that's great, but it's part of the work. There's a balance there. So I just found that interesting. I don't think I would have thought this is something I was interested in until now that I've been on these projects for a while. And I've started noticing a theme where I really enjoy them. Although I realize looking back at former Stephanie days when I was going through Launch Academy and learning to code, I really thought I wanted to be in DevOps. DevOps seemed like the cool kids' corner. They knew how the internet worked. They knew what was happening. They were making it live. And I just thought it seemed really cool. For the record, it is still a cool kids' corner. But I have also learned that the work-life balance isn't great with DevOps because you just never know when you're going to be on call. And that really stood out to me as something that I didn't want to do. And I do like building some features. But essentially, it's that developer acceleration that I really liked because they were the ones that were coming and often building tools and making it easier for then people to then ship their code and get it out into the world and triage. And so I liked the fact that their users were developers versus the people using the application as much, although, I guess, technically both. But the people they were often striving to help the most was the internal team, and that resonated with me. So I guess I have eventually found my way into that space. It wasn't through DevOps, but it is now through this idea of projects that need some rescuing. CHRIS: I love that you've spent enough time now to figure out what it is that draws you in the work and the shape of projects that is meaningful to you. Interestingly, I find myself not on the opposite side of things...you know, we're always looking for a disagreement, and this isn't a disagreement, but this is a thing on which we differ a surprising amount because I do like the early-stage stuff, the new, the breaking ground, all of that exciting whatnot. But how do I not make this a more complicated statement? I appreciate that you have the point of view that you do. I think the world needs more of what you're doing than the inclination that I have, like; I want to start something bright, and fresh, and new, and I can see so much progress immediately in front of me. And this is amazing. But the hard, meaningful work like maintenance, and support, and legacy, and rescue where necessary is such a critical aspect of the work. I see this in open source so often where there are people who are like; I made an open-source project; this is great. I hacked for a bunch of weekends, and look; I made a thing. And then the support burden builds up. And open source can be this wildly undervalued thing overall. And the maintenance of open source is even more so, and you have this asymmetry between the people that are using it and don't think that their voice is one of the thousands that are out there requesting a new feature or anything like that. The handful of people that I see out there in the world that come along later in the lifespan of an open-source project and just step in to do maintenance, my goodness, is that heroic work, just quiet, necessary heroic work. And what you're describing feels sort of similar but at the project level. And I don't know; I'm sort of like silent. I'm out loud on a podcast, not silently at all judging myself because I'm like, I feel like you're doing the thing over there. That seems like a good thing. But I also like my early projects... [laughs] STEPH: I think they're...I mean, we need each other. I need you to start the code, and the applications for them to then need some help down the road [laughs] to [crosstalk 24:30]. CHRIS: But I need to do a bad enough job that we have to be rescued by you. STEPH: [laughs] CHRIS: Hey, don't you worry, friend, I'm doing a terrible...no, I think I'm doing an okay [laughter] job. Hopefully, I'm avoiding those traps, but it's hard to know when you're writing legacy code, you know. STEPH: It is hard for the reasons we were talking about earlier. Like, those technical discussions build-up, and then if you don't really have a space to then address it, then it just keeps getting sidelined until you suddenly get to this point of it's either we come to a grinding halt because we can't ship work, or we find ways to start bringing this into our process. And so that's the other part of the Rails Rescue projects is often looking at the team's process and figuring out, okay, instead of hiring consultants to come in and then try to help with this, how else can they also integrate this into their own project? So then, once thoughtbot lives, they now have ownership of this, and they can carry it forward as well. There is an aspect of this work that I'm still working on, and it comes around to the definition of work because if you go into a team or a project that's like, hey, we really need help with X. We really need help with addressing all these errors. Or we really need help improving developer happiness or getting test coverage in place. Finding out exactly how you're going to tackle that, are you going to join a team of the other developers? Like, are you looking for more of a mentorship? Like, hey, we're going to work alongside your team to then mentor them to then bring this into their own process and their own habits, so then they feel empowered to address this in the future. Are we doing this more as a triage where then we have a specific goal or two that then we're going to meet? And then once we get stuff out of this on fire state, then maybe we start pairing with other people. Or are we going to work closely with the people who are fighting fires with the bug reports and the errors? There are a bunch of different ways that you can tackle that. And I think it really helps define the success of that engagement and then your outcomes because otherwise, I feel like you can get distracted by so much. Because there's so much that's going to try to get your attention that you want to work on and fix. So you have to be very upfront about there are different areas that we can work on. Let's figure out some metrics together that we're really going after to then help define what does success look like for this first iteration of our work? And then what's the long-term plan for this work? Then how do we keep it going forward? How do we empower the team to keep this work going forward? And that's an area that I've learned just from trial and error from being part of these projects. And I'm very interested in still cultivating that skill and figuring out what's the area that we're focused on? CHRIS: There's something that you said in there that I want to hone in on, which is the idea of you've learned from going on so many of these different projects, and you're carrying forward ideas that you have. But I think more generally, there's something interesting in what you were just saying there around you've worked on a bunch of different projects at different organizations with certain things that they were great at, with certain things that they struggled with at different sizes. And you're able to bring all that experience to bear on each project. But I think also taking a step back, as you were describing, you're like, I think I've figured out what it is that I like and the type of projects that I want to do. I cannot say enough good things about working in a consultancy for a while because, my goodness, you get to try out a bunch of different stuff. And A, you get to learn a ton about how to do the work, and how to communicate, and different technologies and all of that. But you also get to figure out what it is that you might want to double down on and lean into in terms of the work. That's definitely a big part of my story. Seven years at thoughtbot, I tried a lot of different stuff, worked at a lot of different companies. And I would describe it as I found a lot of things that I didn't want. And then there's that handful of things that I really did want, and I was able to then more intentionally pursue that. So for anyone out there that's considering it, working at a consultancy is fantastic, or at least it has fantastic elements to it. It also can be complicated as you talk about finding organizations and having to, you know, if you're brought in for a certain job, but when you get there, you're like, "Ooh, I know you want me to fix bugs, but actually, I think I just need to work with your team because they're the ones writing the bugs. And why are they writing the bugs" "Well, because the salespeople are selling things, and then we have timelines." Like, we got to start at the very top of this whole pyramid and fix it. And so it can be very complicated. But there's so much that you can learn about yourself in the process, in the work, and I adored that portion of my career. STEPH: Yeah, I totally agree. Anytime someone mentions, they're like, "Oh, consultancy work. What's that like?" And I remember it was a couple of years ago I mentioned I was working for a consultancy, and they were like, "Oh, you must travel a lot." I was like, "No, [laughter] I stay put. I just work from an office in Boston." But I remember that caught me off guard because I hadn't considered that I was supposed to travel, but that makes sense that you think of consultants that travel. But when I meet people or talk to people, and they're like, "Oh, you've been at thoughtbot for five-plus years, and how's that going? And what's it like to be at a consultancy?" And exactly what you just said, it's the variety that I really like and getting to try on so many different hats and see how different teams and processes work and then identify like, oh, that worked really well for that team, or this isn't working well for that team. I have really enjoyed that. And it can be a roller coaster because you have to get really good at onboarding. You have to go through that initial phase of like; I swear I'm smart. I will get up to speed quickly, and I will learn things. But it's a period that you just have to go through with each team that you join, but you do it twice a year, maybe three times a year. And so you get comfortable with that over time. So there are definitely some challenges that then have to fit your personality and things that work for you and bring you joy. And I completely understand that it's not for everybody, just kind of I really enjoy product work, but I also really enjoy being able to move around to different teams and help folks. CHRIS: I love the idea that as a consultant, your job is to just walk through airports and high-five every Accenture billboard in it and just go up to the wall and pay your respects. But no, no, that is not our version of consulting. [laughs] STEPH: That's why I have so much time for The Bike Shed. It's because I'm just, you know, I'm in different airports high-fiving signs. And then this is my real job; Bike Shed is my real job. CHRIS: Oh, that would be fun. STEPH: [laughs] You know, I have such a fondness of Bike Shed that now something interesting has happened where someone was like, "Oh, you're bike-shedding." And they're not being mean, but they're just like, "Oh, we're totally bike-shedding," or "This is dissolving into bike-shedding." And I'm like, oh, bike-shedding, hooray. And I'm like, oh, wait, bad. [laughter] And I have to catch myself each time. CHRIS: Yeah, we've taken away a lot of the meaning. Well, I mean, have we or do we live up to it every single week? Who can say? But I, too, have a fondness for this phrase, perhaps not aligned with what it is actually meant to signify. STEPH: On a slightly different tech-related note, there is a gem that I'm really excited to check out. I saw it mentioned on the paralleltests gem, which is what helps you run your tests in parallel, and it's what we're currently using. But you can group your tests in different ways. And right now, we're using the runtime strategy where essentially then we use the output from RSpec where we know how long each file took to run. And then paralleltests will then use that data to then figure out, okay, how should I split up your test file? So then try to balance them as evenly as possible. We're at that point, though, where we've talked about tentpoles, so we have certain files that, say, take 10 minutes; other files will only take two minutes. And that balance is really throwing off our ability to then bring down the CI build time. So on paralleltests, there's reference to another gem called parallelsplit_test, where then you can run multiple test scenarios that are in one file but then split them out across different processes or different machines. And that is exactly what I want in my life right now. I haven't checked it out yet, so I feel like I'm giving a daily sync update of like, I'm going to go off and explore this thing. I will report back and see how it goes. [laughs] In the past, I usually try to say, "I've tried this thing, and this is how it went," nope, opposite today. I am sharing the thing I'm going to try, and then hopefully, it goes well. CHRIS: Well, either way, we should definitely report back. That's the truth. I like that you're leading us into this and giving us a preview. But then yeah, we'll see where we get to. That does sound like the thing you want, though. So I hope it goes well. STEPH: Yeah, we've learned at this point where we are splitting work across different machines that until we address some of those tentpole concerns, adding more machines won't help us because then a machine's going to run as long as the longest file. So we've been doing some manual work to split up those files. That's not the best, but it does help you see some results. So then, at least you know you're making progress. So now we really need to find a way to automate that because we don't want someone to have to manually figure out where are the tentpoles, split those files up, commit that, and then keep track of, like, do we have another tentpole on the horizon? We really need a gem or something to help us automate that process. So yeah, I will be happy to report back. MIDROLL AD: And now a quick break to hear from today's sponsor, Studio 3T. When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy. And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase. You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free. That's studio3t.com/free. STEPH: Pivoting just a bit, we have a listener question. This question comes from Steve Polito. And Steve wrote in, "Longtime listener, first-time thoughboter." Yay. Yay is my addition. Anything that goes up in voice is probably my addition, [laughs] just so people know. All right, back to what Steve said. "Why do so many developers and agencies, thoughtbot included, replace the default test suite in Rails with RSpec? Not only does Rails provide a fully functional test suite by default," looking at you Minitest, "but it's also well-documented and even provides the ability to run system tests. Rails is built on the principle of convention over configuration. And it seems odd to me that so many developers want to override such a fundamental piece of framework." Thanks in advance, [singing] Steve Polito. Steve, I hope it's okay I sang your name [laughs] because we're here now. That is an awesome question. I'm going to give what may be less of an awesome answer which is, well, one; Steve highlights that people will then replace Minitest with RSpec. I haven't done that. I haven't actually gone into a project and said, "Okay, we need to replace your test suite and bring in RSpec instead." But if I'm starting out a project, I do have a heavy preference for RSpec, and frankly, that's just from experience. Like, that's what I was raised on, to say it in that way. [laughs] RSpec is what I know; it's what I'm used to. It's what, even when I joined thoughtbot, was just the framework that we used for all of our testing and what we focused on so heavily. So frankly, for me, it's just a really strong bias. I know it's something that I'm really good at. I know it's something that works really well. I know it's well-documented. I know it's also very accessible for other people to use. But actually replacing it on a different project, I don't think I would do that. I'd have to have a really strong reason, or maybe if we haven't actually started testing anything yet, to then replace it because that feels a bit aggressive to me. But then it just depends on the situation, I suppose. But yeah, overall, I just default to RSpec because that's what I'm accustomed to, and it's the testing framework that I know. CHRIS: Yeah, I think my answer is largely the same. It's the thing that I've worked with by far the most. Similarly, I've been on projects that were using Minitest, and therefore I used Minitest because it's definitely not worth the effort to switch. But in a lot of...well, I will say this, I've much less experience, and this may be less true over time. But there were many things that drew me to RSpec, and that continues to be interesting to me in the RSpec world. Even things as small as the assertion syntax, assertequal is the method that's, you know, this is how you do an assertion in Minitest, and it's assertequal expected, actual. That's the order of the arguments. It's expected first and then actual. That makes sense, probably with the expected, but I would get that wrong constantly. I do get that sort of thing wrong. They're just positional arguments that there's nothing about this that tells me which way to go. And so it's very easy to get failure messages that are inverted, and so it's just this tiny little thing. But with RSpec, we end up with expect and then in parentheses, the thing that we are expecting to equal the other thing, and it just reads a little more honestly. It fits within the Ruby mindset in my world. I want my code to be as expressive as possible, and Minitest feels much lower level to me. It feels more, you know, assert as a word is just...I'm not asserting. That just feels so formal. And so these are, again, to be clear, very, very small things, but they all add up. And there's a reason that we're using Ruby overall. And there's a reason that we're using Rails is this expressiveness is a big part of it for me, so I'll cling to that. I'll hold on to that as something that's true. Also, Rspec's mocking support, rspec-mocks as the library, I found to be really fantastic, and I've grown very comfortable working with it. And I know how and where to use that. I also have so much built-up knowledge, like the idea of when to use let and not use let in RSpec. It's just this deep thing that I know about. I'm sure there's an equivalent in the Minitest world, but I would have to have a different understanding in argument, and that conversation would just feel different. I think the other thing that's worth saying is this is a default for us at this point that I personally have not felt the need to reconsider. When I've worked on projects that have used Minitest, I certainly wasn't called to it. I wasn't like, oh, this seems really interesting; I'm going to lean into this more. I was like, I miss RSpec. And some of that is, again, just familiarity. But at the end of the day, we only have so much time to do things. And so, I firmly stand by my not reconsidering my testing option at this point. Like, RSpec does the things that I want. It does it really well. Critically, I'm able to build a system and write a test suite and maintain that test suite over time and have it tell me the truth as to whether or not my application should be deployed to production. That is the measure. That's the thing that I care about. I think it's maybe a little bit slower than Minitest, but I'm fine with that. I have solutions to that problem. And the thing that I care about is when the test suite is green, do I feel confident deploying? RSpec has helped me for years on that journey. And I've never questioned whether or not I should go back to the drawing board and revisit that consideration. So initially, it was probably because it was the thing that we were all using, and then that is for me why it has stuck around. And I love RSpec. I think how many episodes have we just said, "Thanks, RSpec," as a little aside? So we do love it in a deep way. STEPH: Probably not enough episodes have we said that. [laughs] Yeah, I like what you said where you haven't felt the need to switch over or to move away from RSpec. And I wonder, looking back at some of the earlier projects that I joined that were using RSpec, I don't know if maybe they chose RSpec at that time because RSpec had more of those features built-in, and Minitest was still working on those. Maybe they were parallel at the time; I'm not sure. But I like what you said about you just haven't had a need to go back and change. At this point, if I switched over to Minitest, it would definitely be a learning curve for me, which is totally fine. But yeah, I'm just happy with it, so I stick with it. And I also appreciate that idea that, yeah, unless you're new in a project, I wouldn't encourage someone to then switch over to something else unless I feel like there's just a lot of pain for some reason with the current testing setup. There has to be a reason. There has to be a drive. It can't be just a personal bias of like, I know this thing, so I want to use it. There's got to be a better reason that benefits the whole team versus just a personal preference. But overall, I think it comes down to for us; it's just a choice because it's the familiar choice. It's the one that we know. But I think Minitest and RSpec are both so widely supported. I was thinking about that convention over configuration. And yes, Rails ships with Minitest, but RSpec is so common that I don't feel like I'm breaking convention at that point. They're both so widely supported and used that I feel very comfortable going with either option. And then it's just my personal preference for RSpec. So thanks, Steve, for sending in that question. And for anyone else that has a question that you would love to share with Chris and I, you can reach us in a couple of different ways. You can reach us on Twitter via @_bikeshed. You can also go to the website, bikeshed.fm/content. We will drop some links in the show notes. But if you go there, then you can send a question or also email us directly at hosts@bikeshed.fm. And we're running a little low on listener questions, so we would love to have a listener question from you. And we would love to talk about anything that y'all want to talk about, okay, within reason, you know, triathlons, Brussel sprouts, things like that. All of that falls within the wheelhouse. CHRIS: Normal stuff. STEPH: Normal stuff, yeah. CHRIS: And to be clear, despite the fact that Steve did recently become a thoughtboter, you don't have to be a thoughtboter to send in a listener question. [laughs] In fact, it's much more common to not be a thoughtboter when sending in a listener question. But we'll take them from anybody. We're happy to chat with you. STEPH: On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Being pregnant is hard, but this tapas episode is good! Steph discovered and used a #yelling Slack channel and attended a remote magic show. Chris touches on TypeScript design decisions and edge cases. Then they answer a question captured from a client Slack channel regarding a debate about whether I18n should be used in tests and whether tests should break when localized text changes. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Emma Bostian (https://twitter.com/EmmaBostian) Ladybug Podcast (https://www.ladybug.dev/) Gerrit (https://www.gerritcodereview.com/) Gregg Tobo the Magician (https://astonishingproductions.com/) Sean Wang - swyx - better twitter search (https://twitter.com/swyx/status/1328086859356913664) Twemex (https://twemex.app/) GitHub Pull Request File Tree Beta (https://github.blog/changelog/2022-03-16-pull-request-file-tree-beta/) Sam Zimmerman - CEO of Sagewell Financial on Giant Robots (https://www.giantrobots.fm/414) TypeScript 4.1 feature (https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/) The Bike Shed: 269: Things are Knowable (Gary Bernhardt) (https://www.bikeshed.fm/269) TSConfig Reference - Docs on every TSConfig option (https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAccess) Rails I18n (https://guides.rubyonrails.org/i18n.html) This episode is brought to you by Studio 3T (https://studio3t.com/free). Try Studio 3T's full suite of features for 30 days, no payment details needed. Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. There are a couple of new things in my world, so one of them that I wanted to talk about is the fact that being pregnant is hard. I feel like this is probably a known thing, but I feel like I don't hear it talked about as much as I'd really like, especially in sort of like a professional context. And so I just wanted to share for anyone else that may be listening, if you're also pregnant, this is hard. And I also really appreciate my team. Going through the first trimester is typically where you experience a lot of morning sickness and fatigue, and I had all of that. And so I was at the point that most of my days, I didn't even start till about noon and even some days, starting at noon was a struggle. And thankfully, the thoughtbot client that I'm working with most of the teams are on West Coast hours, so that worked out pretty well. But I even shared a post internally and was like, "Hey, I'm not doing great in the mornings. And so I really can't facilitate any morning meetings. I can't be part of some of the hiring intros that we do," because we like to have a team lead provide a welcoming and then closing for anyone that's coming for interview day. I couldn't do those, and those normally happen around 9:00 a.m. for Eastern Time. And everybody was super supportive of it. So I really appreciate all of thoughtbot and my managers and team being so great about this. Also, the client team they're wonderful. It turns out growing a little human; I'm learning how hard it is and working full time. It's an interesting challenge. Oh, and as part of that appreciation because…so there's just not a lot of women that I've worked with. This may be one of those symptoms of being in tech where one, I haven't worked with tons of women, and then two, working with a woman who is also pregnant and going through that as well. So it's been a little bit isolating in that experience. But there is someone that I follow on Twitter, @EmmaBostian. She's also one of the co-hosts for the Ladybug Podcast. And she has been just sharing some of her, like, I am two months sleep deprived. She's had her baby now, and she is sharing some of that journey. And I really appreciate people who just share that journey and what they're going through because then it helps normalize it for me in terms of what I'm feeling. I hope this helps normalize it for anybody else that might be listening too. CHRIS: I certainly can't speak to the specifics of being pregnant. But I do think it's wonderful for you to use this space that we have here to try and forward that along and say what your experience is like and share that with folks and hopefully make it a little bit better for everyone else out there. Also, you snuck in a sneaky pro-tip there, which is work on the East Coast and have a West Coast team. That just sounds like the obvious correct way to go about this. STEPH: That has worked out really well and been very helpful for me. I'm already not a great morning person; I've tried. I've really strived at times to be a morning person because I just have this idea in my head morning people get more stuff done. I don't think that's true, but I just have that idea. And I'm not the world's best morning person, so it has worked out for many reasons but yeah, especially in helping me get through that first trimester and also just supporting family and other things that are going on. Oh, I also learned a pro-tip about Twitter. This is going to seem totally random, but it was relevant when I was searching for stuff on Twitter [laughs] that was related to tech and pregnancy. But I learned...because I wanted to be able to search for something that someone that I follow what they said but I couldn't remember who said it. And so I found that in the search bar, I can add filter:follows. So you can have your search term like if you're looking for cake or pregnancy, or sleep-deprived and then look for filter:follows, and then that will filter the search results to everybody that you follow. I imagine that that probably works for followers too, but I haven't tried it. CHRIS: I like the left turn you took us on there but still keeping it connected. On the topic of Twitter search, they apparently have a very powerful search, but it's also hidden, and you got to know the specific syntax and whatnot. But there is a wonderful project by Shawn Wang, AKA Swyx, on the internet, bettertwitter.netlify.com is the URL for it. I will share a link to his tweet introducing it. But it's a really wonderful tool that just provides a UI for all of these different filters and configurations. And both make discoverability that much better and then also make it easy to just compose one of these searches and use that. The other thing that I'll recommend is, I think it's a Chrome plugin. I'm guessing is what I'm working with here like a browser extension, but it's called Twemex, T-W-E-M-EX. And there's a sidebar in Twitter now, which just seems wonderful and useful. So as I'm looking at a Swyx post here, or a tweet as they're called on Twitter because I know that vernacular, there's a sidebar which is specific to Shawn Wang. And there's a search at the top so I can search within it. But it's just finding their most popular tweets and putting that on a sidebar. It's a very useful contextual addition to Twitter that I found just awesome. So that combination of things has made my Twitter experience much better. So yeah, we'll have show notes for both of those as well. STEPH: Nice. I did not know about those. This may cause someone to laugh at me because maybe it's easier than I think. But I can never remember that advanced search that Twitter does offer; I have to search it every time. I just go to Google, and I'm like, advanced Twitter search, and then it brings up a site for me, and then I use that as the one that Twitter does provide. But yeah, from the normal UI, I don't know how to get there. Maybe I haven't tried hard enough. Maybe it's hidden. CHRIS: It's like they're hiding it. STEPH: Yeah, one of those. [laughs] CHRIS: It's very costly. They have to like MapReduce the entire internet in order to make that search work. So they're like, well, what if we hide it because it's like 50 cents per query? And so maybe we shouldn't promote this too much. STEPH: [laughs] CHRIS: And let's just live in the moment, everybody. Let's just swim in the Twitter stream rather than look back at the history. I make guesses about the universe now. STEPH: [laughs] On a different note, I also discovered at thoughtbot in our variety of Slack channels that we have a yelling channel, and I had not used it before. I had not hung out there before. It's a delightful channel. It's a place that you just go, and you type in all caps. You can yell about anything that you would like to. And I specifically needed to yell about Gerrit, which is the replacement or the alternative that we're using for GitHub or GitLab, or Bitbucket, or any of those services. So we're using Gerrit, and I've been working to feel comfortable with the UI and then be able to review CRs and things like that. My vernacular is also changing because my team refers to them as change requests instead of pull requests. So I'm floating back and forth between CRs and PRs. And because I'm in Gerrit world, I missed some of the updates that GitHub made to their pull request review screen. And so then I happened to hop in GitHub one day, and I saw it, and I was like, what is this? So that was novel. But going back to yelling, I needed to yell about Gerrit because I have not found a way to collaborate with someone who has already pushed up changes. I have found ways that I can pull their changes which then took a little while. I found it in a sneaky little tab called download. I didn't expect it to be there. But then the actual snippet it's like, run this in your terminal, and this is then how you pull down the changes. And I'm like, okay, so I did that. But I can't push to their existing changes because then I get like, well, you're not the owner, so we're going block you, which is like, cool, cool, cool. Okay, I kind of get that because you don't want me messing up somebody else's content or something that they've done. But I really, really, really want to collaborate with this person, and we're trying to do something together, and you're blocking me. And so I had to go to the yelling channel, and I felt better. And I'm yelling again. [laughs] Maybe I don't feel that great because I'm getting angry again talking about it. CHRIS: You vented a little into the yelling channel; maybe not everything, though. STEPH: Yeah, I still have more to vent because it's made life hard. Every time I wanted to push up a change or pull down someone else's changes, there are now all these CRs that then I just have to go and abandon, which is then the terminology for then essentially closing it and ignoring it, so I'm constantly going through. And if I do want to pull in changes or collaborate, then there's a flow of either where I abandon mine, or I pull in their changes, but then I have to squash everything because if you push up multiple commits to Gerrit, it's going to split those commits into different CRs, don't like that. So there are a couple of things that have been pain points. And yeah, so plus-one for yelling channels, let people get it out. CHRIS: Okay, so definitely some feelings that you are working through here. I'm happy to work together as a team to get through some of them. One thing that I want to touch on is you very quickly hinted at GitHub has got a bunch of new things that are cool. I want to talk about those. But I want to touch [laughs] on an anecdote. You talked about pushing something up to someone else's branch. You're like, oh, you know, I made some changes locally, and I'm going to push them up. I had an interesting experience once where I was interacting with another developer. I had done some code review. They weren't quite understanding where I was. They had a lot of questions. And finally, I said, you know what? This will just be easier. Here, I pushed up a commit to your branch, so now you can see what I'm talking about. And I thought of this as a very innocuous act, but it was not interpreted that way. That individual interpreted it in a very aggressive sort of; it was not taken well. And I think part of that was related to I think of Git commits as just these little ephemeral things where you're like, throw it out, feel free. This is just the easiest way for me to communicate this change in the context of the work that you're doing. I thought I was doing a nice favor thing here. That was not how it went. We had a good conversation after I got to the heart of where we both were emotionally on this thing. It was interesting. The interaction of emotion and tech is always interesting. But as a result, I'm very, very careful with that now. I do think it's a great way as long as I've gotten buy-in from the person beforehand. But I will always spot check and be like, "Hey, just to confirm, I can just push up a commit to your branch, but are you okay with that? Is that fine with you?" So I've become very cautious with that. STEPH: Yeah, that feels like one of those painful moments where it highlights that the people that you work with that you are accustomed to having a certain level of trust or default trust with those individuals, and then working with someone else that they don't have that where the cup is half-full in terms of that trust, or that this person means well kind of feelings towards a colleague or towards someone that they're working with. So it totally makes sense that it's always good to check and just to be like, "Hey, I'd love to push up some changes to your branch. Is that cool?" And then once you've established that, then that just makes it easier. But I do remember that happening, and yeah, that was a bit painful and shocking because we didn't see that coming and then learned from it. CHRIS: I do think it's an important thing to learn, though, because for me, in that moment, this was this throwaway operation that I thought almost nothing of, but then another individual interpreted it in a very different way. And that can happen, that can happen across tons of different things. And I don't even want to live in the idealized world where it's just tech; we're just pushing around zeros and ones; there's no human to this. But no, I actually believe it's a deeply human thing that we're doing here. It's our job to teach the computers to be a little closer to us humans or something like that. And so it was a really pointed clarification of that for me where it was this thing that I didn't even think once about, no less twice, and yet someone else interpreted it in such a different way. So it was a useful learning situation for me. STEPH: Yeah, I totally agree. I think that's a really wise default to have to check in with people before assuming that they'll be comfortable with something that we're comfortable with. CHRIS: Indeed. But shifting back to what you mentioned of GitHub, a bunch of new stuff came in GitHub, and you were super excited about it. And then you went on to say other things about another system. [laughs] But let's talk about the great things in GitHub. What are the particular ones that have caught your eye? I've seen some, but I'm intrigued. Let's compare notes. STEPH: So this is one of those where I hadn't seen GitHub in quite a while, and then I hopped in, and I was like, this is different. But some of the things that did stand out to me right away is that on the left-hand side, I can see all of the files that have been changed, and so that's a really nice tree where I just then immediately know. Because that was one of the things that I often did going to a PR is that I would see what files are involved in this change because it was just a nice overview of what part of the applications am I walking through? Are there tests for this? Have they altered or added tests? And so I really like that about it. I'm sure there's other stuff. But that is the main thing that stood out to me. How about you? CHRIS: Yeah, that sidebar file tree is very, very nice, which I find surprising because I don't use a file tree in my editor. I only do fuzzy finding to jump to files. But I think there's something about whenever GitHub had the file list; these are all the files that are changed. I'm like, this is just noise. I can't look at this and get anything out of it. But the file tree is so much more...there's a shape to it that my brain can sort of pattern match on. And it's just a much more discoverable way to observe that information. So I've really loved that. That was a wonderful one. The other one that I was surprised by is GitHub semantic code analysis; stuff has gotten much, much better over time subtly. I didn't even notice this happening. But I was discussing something with someone today, and we were looking at it on GitHub, and I just happened to click on an identifier, and it popped up a little thing that says, "Oh, do you want to hop to the references or the definition of this?" I was like, that is what I want to do. And so I hopped to the definition, hopped to the definition of another thing, and was just jumping around in the code in a way that I didn't know was available. So that was really neat. But then also, I was in a pull request at one point, and someone was writing a spec, and they had introduced a helper just like stub something at the bottom of a given spec file. And it's like, I feel like we have this one already. And I just clicked on the identifier. I think it might have actually been a matcher in RSpec, so it was like, have alert. And I was like, oh, I feel like we have this one, a matcher specific to flash message alerts on the page. And I clicked on it, and GitHub provided me a nice little inline dialog that showed me all of the definitions of have alert, which I think we were up to like four of them at that point. So it had been copied and pasted across a couple of different files, which I think is totally fine and a great way to start, but they were very similar implementations. I was like, oh, looks like we actually already have this in a couple of places, maybe we clean it up and extract it to a common spec support thing, and ta-da, I was able to do all of that from the GitHub pull requests UI. And I was like, this is awesome. So kudos to the GitHub team for doing some nifty stuff. Also, can I get into the merge queue? Thank you. ... STEPH: [laughs] There it is. That is very cool. I didn't know I could do that from the pull request screen. I've seen it where if I'm browsing code that, then I can see a snippet of where everything's defined and then go there, but I hadn't seen that from the pull request. I did find the changelogs for GitHub that talk about the introduction of having the tree, so we'll be sure to include a link in the show notes for that too. But yes, thank you for letting me use our podcast as a yelling channel. It's been delightful. [laughs] Mid-roll Ad Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. CHRIS: Well, speaking of podcasts, actually, there was an interesting thing that happened where the CEO of Sagewell Financial, the company of which I am the CTO of, Sam Zimmerman is his name, and he went on the Giant Robots Podcast with Chad a couple of weeks ago. So that is now available. We'll link to that in the show notes. I'll be honest; it was a very interesting experience for me. I listened to portions of it. If we're being honest, I searched for my name in the transcript, and it showed up, and I was like, okay, that's cool. And it was interesting to hear two different individuals that I've worked with either in the past or currently talking about it. But then also, for anyone that's been interested in what I'm building over at Sagewell Financial and wants to hear it from someone who can probably do a much better job of pitching and describing the problem space that we're working in, and all of the fun challenges that we have, and that we're hopefully living up to and building something very interesting, I think Sam does a really fantastic job of that. That's the reason I'm at the company, frankly. So yeah, if anyone wants to hear a little bit more about that, that is a very interesting episode. It was a little weird for me to listen to personally, but I think everybody else will probably have a normal experience listening to it because they're not the CTO of the company. So that's one thing. But moving on, I feel like today's going to be a grab bag episode or tapas episode, lots of small plates, as we were discussing as we were prepping for this episode. But to share one little thing that happened, I've been a little more removed from the code of late, something that we've talked about on and off in previous episodes. Thankfully, I have a wonderful team that's doing an absolutely fantastic job moving very rapidly through features and bug fixes and all those sorts of things. But also, I'm just not as involved even in code review at this point. And so I saw one that snuck through today that, I'm going to be honest, I had an emotional reaction to. I've talked myself down; we're fine now. But the team collectively made the decision to move from a line length of 80 characters to a line length of 120 characters, and I had some feelings. STEPH: Did you fire everybody? [laughs] CHRIS: No. I immediately said, doesn't really matter. This is the whole conversation around auto-formatting tools is like we're just taking the decision away. I personally am a fan of the smaller line length because I like to have multiple files open left to right. That is my reason for it, but that's my reason. A collective of the developers that are frankly working more in the code than I am at this point decided this was meaningful. It was a thing that we could automate. I think that we can, you know, it's not a thing that we have to manage. So I was like, cool. There we go. The one thing that I did follow up on I was like, okay; y'all snuck this one in, it's fine, I'm fine with it. I feel fine; everything's fine. But let's add that to the git-blame-ignore-revs file, which is a useful thing to know about. Because otherwise, we have a handful of different changes like this where we upgrade Prettier, and suddenly, the manner in which it formats the files changes, so we have to reformat everything at once. And this magical file that exists in Git to say, "Hey, ignore this revision because it is not relevant to the semantic history of the app," and so it also takes that decision out of the consideration like yeah, should we reformat or not? Because then it'll be noisy. That magical file takes that decision away, and so I love that. STEPH: I so love the idea because you took vacation recently twice. So I love the idea of there was a little coup and people are applauding, and they're like, while Chris is on vacation, we're going to merge this change [laughs] that changes the character line. And yeah, that brings me joy. Well, I'm glad you're working through it. Sounds like we're both working through some hard emotional stuff. [laughs] CHRIS: Life's tricky, is all I'm going to say. STEPH: I am curious, what prompted the 80 characters versus 120? This is one of those areas that's like, yeah, I have my default preference like you said. But I'm more intrigued just when people are interested in changing it and what goes with it. So do you remember one of the reasons that 120 just suited their preferences better? CHRIS: Frankly, again, I was not super involved in the discussion or what led them to it. STEPH: [laughs] CHRIS: My guess is 120 is used...I think 80 is a pretty common one. I think 120 is another of the common ones. So I think it's just a thing that exists out there in the mindshare. But also, my guess is they made the switch to 120 and then reformatted a few files that had like, ah, this is like 85 characters, and that's annoying. What does it look like if we bump it up? And so 120 provided a meaningful change of like, this is a thing that splits to four lines if we have an 80 character thing, or it's one line if it's 120 characters, which is a surprising thing to say, but that's actually the way it plays out in certain cases because the way Prettier will break lines isn't just put stuff on the next line always. It's got to break across multiple lines, actually. All right, now that we're back in the opinion space, I have a strong one. STEPH: This is The Bikeshed. We can live up to that name. [laughs] CHRIS: So I do want an additional configuration in Prettier Ruby. This is the thing I'll say. Maybe I can chase down Kevin Newton and see if he's open to this. But when Prettier does break method call with arguments going into it but no parens on that method call, and it breaks out to multiple lines, it does the dangling indent thing, which I do not like. I find it distasteful; I find it noisy, the shape of the code. I'm a big fan of the squint test. I know that from Sandi Metz, I believe, or maybe it's Avdi Grimm. I associate it with both of them in my mind. But it's just a way to look at the code and kind of squint, and you see the shape of it, and it tells you something. And when the lines break in that weird way, and you have these arbitrary dangling indents, the shape of the code is broken up. And I don't feel so strongly. I actually regularly stop myself from commenting on pull requests on this because it's very easy. All you need to do is add explicit parens, and then Prettier will wrap the line in what I believe is a much more aesthetically pleasing, concise, consistent, lots of other good adjectives here that are definitely just my preferences and not facts about the world. But so what I want is, Prettier, hey, if you're going to break this line across multiple lines, insert the parens. Parens are no longer optional for breaking across multiple lines; parens are only optional within a given line. So if we're not breaking across lines, I want that configuration because this is now one of those things where I could comment on this. And if they added the optional parens, then Prettier would reform it in a different way. And I want my auto formatter don't give me ways to do stuff. Like, constrain me more but also within the constraints of the preferences that I have, please, thank you. STEPH: I love all the varying levels there [laughter] of you want a thing, but you know it's also very personal to you and how you're walking that line and hopping back and forth on each side. I also love the idea. We have the idea of clean code. I really want something that's called distasteful code now [laughs] where you just give examples of distasteful code, yes. Well, I wish you good luck in your journey [laughs] and how this goes and how you continue to battle. I also appreciate that you mentioned when you're reviewing code how you know it's something that you really want, but you will refrain from commenting on that. I just appreciate when people have that filter to recognize, like, is this valuable? Is it important? Or, like you said, how can we just make this more of the default so then we don't even have to talk about it? And then lean into whatever the default the team goes with. CHRIS: Well, thank you. I very much appreciate that because, frankly, it's been very difficult. STEPH: I do have something I want to yell about but in a very positive way or pranting as we determined or, you know, raving, the actual real term that wonderful listeners pointed out to us. CHRIS: Prant for life. That's my stance. STEPH: We had a magic show at thoughtbot. It was all remote, but the wonderful Gregg Tobo, the magician, performed a magic show for us where we all showed up on Zoom. And it was interactive, and it was delightful, and it was so much fun. And so if you need something fun for your team that you just want to bring folks together, highly recommend. I had no idea I was going to enjoy a magic show this much, but it was a lot of fun. So I'll be sure to include some links in the show notes in case that interests anyone. But yeah, magic. I'm doing jazz hands. People can't see it, but magic. I like how you referred earlier, saying that today is more of like a tapas episode. And I'm realizing that all of my tapas are related to being pregnant, yelling, and magic shows, and I'm okay with that. [laughs] But on that note, what else is on your tapas plate? CHRIS: Actually, a nice positive one that came into the world...I always like when we get those. So this is interesting because I was actually looking back at the history, and I had Gary Bernhardt on The Bike Shed back in Episode 269. We'll include a link in the show notes. But we talked a bunch about various things, including TypeScript. And I was lamenting what I saw as a pretty big edge case in TypeScript. So the goal of TypeScript is like, all right, JavaScript exists, this is true. What can we do on top of that? Let's not fundamentally change it, but let's build a type system on top of it and try and make it so that we can enforce correctness but understand that JavaScript is a highly dynamic language and that we don't want to overconstrain and that we've got to meet it where it is. And so one of the design decisions early on with TypeScript is if you have an array and you say like it's an array of integers, so you have typed that array to be this is an array of int, or it will be an array of number in JavaScript because JavaScript doesn't have integers; they only have numbers. Cool. [laughs] Setting aside other JavaScript variables here, you have an array of numbers. And so if you use element access to say, like, say the name of array is array of nums and then use brackets and you say zero, so get me the first element of that array. TypeScript will infer the type of that to be a number. Of course, it's a number, right? You got an array of numbers, you take a number out of it, of course, you're going to have a number, except you know what's also an array of numbers? An empty array. Well, of course. So there's no way for TypeScript because that's a runtime thing, whether or not the array is full of things or not. Or imagine you get the third element from the array. Well, JavaScript will either return you the third element, which indeed is a number, or undefined because there's no third element in this array. So that is an unfortunate but very understandable edge case that TypeScript was like, listen, this is how JavaScript works. So we're not going to…frankly, we don't think the people embracing TypeScript and bringing it into their world would accept this amount of noise because this is everywhere. Anytime you interact with an array, you are going to run into this, this sort of uncertainty of did I actually get the thing? And it's like, yeah, no, I know how many things are in the array that I'm working with. Spoiler, you maybe don't is the answer. And so, we ran into this edge case in our codebase. We were accessing an element, but TypeScript was telling us, "Yes, definitively, you have an object of that type because you just got it out of an array, which is an array of that type." But we did not; we had undefined. And so we had, you know blah is not a method on undefined or whatever that classic JavaScript runtime error is. And I was like, well, that's very sad. But now we get to the fun part of the story, TypeScript, as of version 4.1, which came out like the week that I recorded with Gary Bernhardt, which was interesting to look at the timeline here. TypeScript has added a new configuration. So a new strictness dial that you can configure in your tsconfig called noUncheckedIndexedAccess. So if you have an array and you are getting an element out of it by index, TypeScript will say, "Hey, you got to check if that's undefined," because to be clear, very much could be undefined. And I was so happy to find this. We turned it on in our codebase. It found the error in the place that we actually had an error and then found a few others that I think probably had errored at some times. But it was just one of those for me very nice things to be able to dial up the strictness and enforce correctness within our codebase, and so I was very happy about it. Other folks may say that seems like too much work. And, you know, I get that, I get that take. I'm definitely on the side of I'm willing to go through the effort to have enforced correctness, but you know, that's a choice. STEPH: Yeah, that's thoughtful. I like that, how you said you can dial up the strictness so then as you are introducing TypeScript, then people have that option. There is an argument there in the back of my head that's like, well, if you're introducing types, then you want to start more strict because then you're just creating problems for yourself down the road. But I also understand that that can make things very difficult to then introduce it to teams in existing codebases. So that seems like a really nice addition where then people can say, "Yeah, no, I really want the strictness. This is why I'm here," and then they can turn that on. CHRIS: So TypeScript in the configuration has strict mode, so you say strict true. And that is a moving target with each new version of TypeScript. But it's their sort of [inaudible 28:14] set of things that are part of strict, but apparently, this one's not in it. So now I'm like, wait, can I have a stricter? Can I have a strictest option? Can I have dial it to 11, please? [laughs] Really rough me up and make sure my code is correct. But it is the sort of thing like when we turn any of these on; it will find things in our codebase. Some of them, we have to appease the compiler even though we know the code to be correct. But the code is not provably correct as it sits in our file. So I am, again, happy to make that exchange. And I like that TypeScript as a project gives us configurability. But again, I am on team where's the strictest button? I would like to push that as hard as I can and live that life. STEPH: Yeah, I like that phrasing that you just said about provably correct. That's nice. CHRIS: That's the world I want to live in, everything you own in the box to the left, which is probably correct. STEPH: [laughs] That's how that song goes. CHRIS: Yeah. This is a reference to move errors to the left, which I think I've referenced before. But now that I'm just referencing Beyoncé and not the actual article, it's probably worth referencing the article, but the idea of, like, if a user hits an error, that's not great. So let's move it back to QA, that's a little further to the left in sort of the timeline. But what if we could move it to an automated test in CI? But what if we could move it into your editor? What if we could move it even further to the left? And so, a type system tends to be sort of very far ratcheted up to the left. It's as early as possible that you can catch these. So again, to reference Beyoncé, everything you own in a box to the left. STEPH: [singing] Everything you own in the box to the left. CHRIS: Thank you for doing the needful work there. STEPH: [laughs] Mid-roll Ad And now a quick break to hear from today's sponsor, Studio 3T. When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy. And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase. You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free that's studio3t.com/free. STEPH: I have a question for you that I'd really love to get your opinion on because I myself I'm waffling back and forth where someone brought up some really great points about a concern or just a question they had brought up around testing and i18n specifically. And I agree with the things that they're saying, but yet, there's also a part of me that doesn't, and so I'm Stephanie divided. And so, I'm trying to figure out where I stand on this. So let me dive in and give you some context; I'm going to share the statement/question that they had asked. So here we go. "One of my priorities has been I should be able to review a test without having to reference any other code. References to i18n means that I have to go over to YAML and make sure the right keys have the right values, and that seems error-prone. In some cases, a lack of a hit in the YAML defers to defaults. If the intent is to override the name of model attribute and error messages and it is coded incorrectly, the code fails silently without translating and uses the humanized attribute name, and that would go undetected. If libraries change structure, it might also fail silently as well, so to me, the only failsafe way is to be fully explicit in test." So this goes with the idea that if you're writing tests and then you're testing text, but it's on the screen or perhaps an email, that you're actually going to assert against that string that is shown to the user instead of referencing the i18n keys. And then that also backs up this person's idea that you really want to not have to jump around. If you're reading a test, everything you really need to know about that test should live very close by. And I really agree with that initial statement; I want everything that's very close to the test, especially if it's anywhere in that expectation line, I really want it close, so I can understand what's the expectation, what's under test, what are the inputs, what's the expected outcome. So I wholeheartedly support that idea. But yet, I am in the camp that I then will use YAML keys instead of providing that exact string because I do look at i18n as a helpful abstraction, and I want to trust that i18n is doing its job. And so that way, I don't have to provide that string that's there because then we're also choosing, okay, well, which language are we going to always use for our test? So this is the part where I feel divided. So I'm going to walk you through some of the reasons that I really support this idea and other reasons that I still use the i18n keys and then get your take on it. So there is a part of me that when I'm using the i18n YAML keys, it does make me sad because it reduces the readability in tests. Sometimes the keys are really well named where maybe it's a mailer.welcomemessage. And I'm like, okay, I understand the gist. I don't need to go see the actual string. I also think they highlighted a really good use case where if you're overriding behavior and it could default to something else, your test is still going to pass, and you don't actually know. So I could see the use case there where if you are overriding, then you want to be explicit about the string that you expect back. I also think there are some i18n messages that are fairly complex, and where then I really would like to see the string. So if you are formatting a date or a time or you're passing in just a lot of variables, then there's a chance that I do want to see how did that actually get generated for the person who's going to be reading it versus just maybe it's garbage text that came out? And I want to validate that the message that we think we're crafting is actually the one that the user is going to see. The case against actually being explicit, my biggest one is because then I do see i18n as a helpful abstraction. And I want to trust this abstraction that it's doing its job and it's doing it well. Because then if I do use explicit strings, it makes me sad if I change text from like hello to welcome, and now I have a failing test. I don't like that idea either. So I'm torn between these two worlds of it is very nice to have everything that you need in a test to be able to understand what is the expectation, but then I also lean into this abstraction and reference the i18n keys. So, Chris, with all of that, that was a bit of a whirlwind, [laughs] what are your thoughts? How do you test this stuff? CHRIS: Honestly, I'm surprised that you've got that much division in your own answer because for me, this is very obvious there's one...no, I'm kidding. This is obviously complicated. Similar to you, I think I'm going to have to give a grab bag of answers because I don't have a singular thought of like it is concretely this or that. I tend to go for explicit strings and tests all the way to...so like the readability of a test, and the conciseness of a test is interesting. I will often see developers extract. Say they're creating a user with a specific email, and then they log in with that email later, and then they expect something else. And so the email is referenced a few times, and they'll extract that into a variable called email. And I personally will tend to not do that. I will inline the literal string like user@example.com, and I'll do it in a few places. And I'm fine with that duplication because I like the readability of any given line that you're reading. So I will make that trade-off within tests. This is the thing I think we've talked about before, but the idea of DRY in tests is like I want to be careful applying that idea, Don't Repeat Yourself, to break apart the acronym. Those abstractions I will use them less than tests. And so I want the explicitness, I want the readability, I want to tell a little story, all of that feels true. That said, to flip it around, one of the things that I'm hearing...so I think I'm hearing a part of this that is around well, we can fail silently because we fail symmetrically in both the implementation and our test. Then an assertion may actually match even though it's matching on a fallback. I think that's a configurable thing. I would actually want my test to raise if I'm referencing an i18n key that is not defined. Now, granted, that's different for languages. And maybe this becomes a more complex story of like in production; in a different locale, it will fail because we don't have 100% parity across all our locale files. But fundamentally, I want to make sure that at least exists in our base, which I think typically would be en-US as the locale. I want to make sure all keys are looked up and found, and it's an error otherwise in our test. So that's a feeling. But am I misunderstanding that part of the story or how that configuration typically works? STEPH: No, I think you've got it. But just to make sure we're on the same page, so if you reference a key that doesn't exist, then it is going to fail. So at least you have your test failure is going to let you know that you've referenced something that doesn't exist. But if you are referencing, like if you want to override the defaults that Rails or i18n has provided for a model and say for an error message, if you reference that, but you want to override it, but then you've forgotten, that does exist. So you're not going to get the failure; you're going to get a different message. So it's probably not a terrible experience for the user. It's not going to crash. They're going to see something, but they're not going to see the custom message that you intended them to see. CHRIS: Gotcha. Okay, well, just to name it, the thing that I was describing, I don't know that that would be the configuration for every system. So I would strongly encourage any system where i18n just has a singular behavior which is we fall back to the key. I want my test to absolutely tell me if that's happening. And that should be a failure of the test. But to the discoverability documentation bit, I do wonder if tooling can actually help answer the question. And as I was describing the wonderful experience I had on GitHub the other day, viewing code as just static characters in a file is both true and also, I think increasingly, a limited view of it. We have editors, and we have code hosting tools that can understand semantically our code a little bit better. There's got to be like 20 Different VS Code plugins that, when you hover on an i18n reference, it will do the lookup for you. That feels like a thing that exists, and if it doesn't, well, now I've nerd-sniped myself, and I got a weekend project. JK, I'm definitely not building that this weekend. But that feels like can we use that to solve this? Maybe not. But that's just another thought of where we have these limitations where it's static, like those abstractions can be useful. But if we can very quickly dereference them, then the cost of the abstraction or that separation becomes smaller, and so the pain is reduced. And I wonder if that's a way to sort of offset it. STEPH: If I can poke at that a little bit more, because I think you're touching on something that I haven't expressed or thought through explicitly, but it's the idea of, like, why do I like the abstraction? What is it that's drawing me towards using these keys? And I think it's because most of the cases, I don't care. I don't care what the string is, and so that feels nice. Like, I understand that, yes, we're referencing something. If that key didn't exist, I'm going to see a failure. So I know that there's text there, and that's why I do lean into referencing the keys instead of the text because it feels good to not have to care about that stuff. And if we do make changes to the text, then it suddenly doesn't fail, and then I have to go update a test because we added a period or added a comma. I think that's the path of more sadness for me. And my goal is always a path of least sadness. So I think that's why I lean into it [laughs], I'm guessing. Is that why you lean into it as well? Or what do you like about referencing the keys over the explicit text? CHRIS: No, I think I share your inclination there, and the reason that you're in favor of it, and I think the consistency like if we're going to use i18n, then we should lean in because it's a non-trivial thing to do like porting to i18n projects, and they're tricky. Getting it right from the first step is also tricky. If you're going to do it, then let's lean in, and thus let's use that abstraction overall. But yeah, same ideas as you. STEPH: Cool. I think that helps validate where I'm at in terms of how I rationalize about this where ultimately, I do like leaning into that abstraction. And as you'd mentioned, some of those porting projects, I haven't been on one specifically, but I've seen that they are a lot of work. And so, if we have that in our system, then we want to continue to use it. It does reduce some of the readability. Like you said, maybe there's a VS Code plugin or some way that then we can help people be able to see if they want that full context in the test and not have to jump over to YAML. But yeah, otherwise, unless it's overriding default behavior or complex, then that's what I'm going to go with is with the keys. But I really appreciate this person's very thoughtful question and approach to testing because, normally or typically, I fully agree with I want full context in the test. And this one was one of those outliers that came up for me, and I had to really think through all the feelings and the reasons that I have for those feelings. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Chris is back from vacation and gives hiring and onboarding updates. Steph has an update about the CI slowdown and scaling CI. They tackle a listener question regarding having some fear around potential merge conflicts. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Deckset (https://www.deckset.com/) parallel_tests (https://github.com/grosser/parallel_tests) paralleltests - important line that may alter the `groupby` strategy (https://github.com/grosser/parallel_tests/blob/9bc92338e2668ca4c2df81ba79a38759fcee2300/lib/parallel_tests/cli.rb#L305) KnapsackPro (https://knapsackpro.com/) rspec-queue (https://github.com/conversation/rspec-queue) Vim Conflicted Overview (https://github.com/christoomey/vim-conflicted#overview) Mastering Git Course on Upcase (https://thoughtbot.com/upcase/mastering-git) Git Object Model (https://thoughtbot.com/upcase/videos/git-object-model) Git Object Model Operations (https://thoughtbot.com/upcase/videos/git-object-model-operations) The Opportunity Will Find You (https://thoughtbot.com/blog/the-opportunity-will-find-you) This episode is brought to you by Studio 3T (https://studio3t.com/free). Try Studio 3T's full suite of features for 30 days, no payment details needed. Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Golden roads are golden. STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. Oh, I also have a new intro that I want to try out. This is thanks to Irmela from Twitter, where it's good morning and hooray; today is Bike Shed day. They technically said Tuesday, but we don't record on Tuesdays. So today is Bike Shed day, so happy Bike Shed day. And hey, Chris, what's new in your world? CHRIS: What is new in my world? Yeah, I loved when I saw that tweet come out. It really warmed my heart. So Tuesday, in theory, is Bike Shed day, but for you and I, Friday is Bike Shed day. It's confusing breaking the fourth wall, as I so often do. But yeah, what's new in my world? I'm back from vacation, which is the thing that I did. For listeners, well, I have been absent the previous week related to vacation and all those sorts of things. But I did what we're going to describe as a not smart thing. It wasn't intentional. The world just kind of conspired in this way. But I had two separate vacation islands that existed in my mind, and then they both kind of congealed, but as they did that, they moved towards each other, but they didn't connect. And so what I ended up with was two weeks back to back where I was out on Thursday and Friday of one week, and then I was back for Monday and Tuesday. And then I was out for Wednesday, Thursday, Friday of the following week. Protip: that's a terrible idea. It's just not enough time to sort of catch up. The whole of it was like the ramp-up to vacation and then the noise of vacation, then getting back and being like, oh, there are so many emails. Let me try and catch up on them. But also, on the very positive side, we had a new hire join the team, and so most of my focus on the days that I was in the office was around getting that new person comfortable on the team, onboarding, spending as much time as possible with them. And so, all total, it was an adventure. And again, I would strongly recommend against this. The world just kind of conspired, and suddenly these three different forces in my life came together. And this was just the shape of things. But yeah, I went on vacation, and it was great. The vacation part was great. STEPH: I will take your advice. So next time I have like two segments of PTO, I'm just going to stitch them together and just go ahead and take that whole intermittent time off. CHRIS: That probably would have been better. Again, someone new joining the team, it was very important to me to get some time with them early on, and so I opted not to do that. But yeah, the attempt to catch up in between was a completely lost effort, I would say. But I think I'm mostly caught up now, having been back in the office for about a week, so yeah. But let's see, what else has been up in my world? It's actually been a while since you and I have chatted based on the various timing and schedules and the nonsense vacation schedule that I had that you so kindly accommodated across a couple of weeks. Let's see, hiring and onboarding; the hiring went really well. We talked about that a bunch of weeks back. But now we're in the onboarding phase. And so next week will be the first week that all four of us on the engineering team are in the office together for the full week. I'm super excited to experience that. We've had different portions of it, with me being on vacation and other folks being on vacation. But now, for the first time, we're really going to feel what it's like as this team. And we're going to have our first retro as a group and all those sorts of things, so I'm very excited to do that. And thus far, all of the interactions that we've had have been really wonderful as a team. And so now it'll be the first time we're just bringing all of those various pieces together. STEPH: I just have to clarify; you said all of y'all in the office together. Do you still mean remotely? CHRIS: Oh, yes, yes, I just mean not on vacation, all present and accounted for on the internet. Remote is another interesting facet of what we're doing here and trying to figure out how to navigate that, particularly where there are some folks that are closer and can potentially get together in the city, that sort of thing, and then folks that are truly remote and making sure that we're...I'm very much of the opinion if we have anyone that's remote, we are remote team, and we must embrace async communication and really lean into that. And I think the benefits of async communication as its own consideration are so worth it. And it's one of those things that's hard to do. It requires careful, intentional thought. It requires more purposeful communication. But I think there are a lot of good things that fall out of that. It's similar to TDD in that way in my mind, like, it's not easy. It's actually quite difficult. But all the effort that I put into trying to learn how to do that has made me a better developer, I think, on all the various fronts. And I think similarly, async communication I believe in as a tool to force just better communication. And so I'm a big believer in it, and I've found a ton of benefit in remote that I'm also a big believer in that now. I, like everyone else, was forced into it as the world was, but I've really come to enjoy it a lot. And so yeah, so, no, not physically in the office, to answer your very short question with a long rambling aside. STEPH: [laughs] I like that comparison. I hadn't thought about it in that way but comparing that thoughtfulness and helpfulness of async communication and then also to TDD, where it's not easy, but the payoff is so worth it, the upfront cost of it. That is something that at thoughtbot, we've had conversations around where there are folks that really value...they want to be around people. They get energy from people, and so they want that option to be able to rent a WeWork space and maybe get together with a colleague once or twice a week, and that was supported by thoughtbot. But we also wanted to express well, if you are together, do treat everything still as a remote work environment. So let's say if you and your colleagues are on a project, but then there's a third person on that project that's remote, you still need to act like everything's remote to make sure that everyone else is still getting to participate and hear everything and be part of the conversation. So just keeping that in mind that yes, we want to support you doing your best work, and if that's around people, that's wonderful. But we are still remote-first, and communication needs to be in that fashion. Well, that's super exciting that you'll have all of the team together. That sounds like it will be wonderful to hear about and then also retros and meetings, and yeah, it sounds like you've got a fun week ahead. CHRIS: Indeed. I'm super excited to see what sort of new things come out of the new voices on the team and practices that each of the individuals have experienced at other companies that we can now fold together. The work that we've done so far has been very much inspired by thoughtbot ideas, and approaches, and workflows, and processes because that's what I brought to the table. But I'm super excited to bring in more voices and see what of that 100% stays on versus does anything change? Do we get entirely new things? So yeah, very excited about all of that. But to revisit a topic that we've talked about in the past, this week is catching up from vacation, so there's a certain amount that will constrain my work. But this was definitely another week of I did not do much coding. I'm trying to think if I did any coding this week. It's possible that the answer is no. The fact that I don't even know the answer to that is an interesting one. I still have in my mind the desire to get back to it, and I think I will. But there's so much other stuff to do. Recently, this week, there's been a lot of vendor selection and contract negotiation, which is an interesting facet of the work, but just trying to figure out, oh, we need platforms to do X, Y, and Z. And it turns out they're wildly costly and have long sales cycles. And how do you go through that, and how do you make sure that we're getting the right thing? And so that's been a big part of my work. Hiring and onboarding, again, has been a big part of it. There's also some amount of communicating back to the broader team - what are we doing? What is the product organization or the engineering team delivering? And so I'm okay at presentations, I think. I'm comfortable with giving presentations. The thing that I struggle with is finding the optimization point in preparation. I will, of my own accord, over-prepare. And that may sound a little bit like, oh, what's my greatest weakness? That I care too much. But I mean it sincerely as like, I would love to find that right amount of like, it's like an hour of preparation for a 15-minute presentation to the team. That's the right ratio. And I just hit that on the head, and it's great. But whenever I know that I need to give a larger presentation, it will distract me. And it's work that can expand to fill whatever time you give it, and so trying to thread that needle is a tricky one for me. STEPH: Yeah, I'm with you. Presentations, for me, they're one of those things that it's very stressful, anxiety-inducing; all the prep feels distracting from some of the other work that I want to do. Or maybe I'm excited about the presentation, and that is the work that I want to do. But it's not until it's done that then I'm like, oh, that was fun. That went well. This was great. It's not until after that then I feel good about it. So the lead-up to it is very stressful. And so if you can optimize that to say, well, I know exactly what this group needs, where I can cut corners, where I have to go into details, that sounds incredibly valuable. I'm curious, so this is probably a bad idea, but it's the only way I really know how to find those boundaries is you got to experiment and tweak a little bit and let yourself fail a little bit or just be very explicit with folks about this is what the presentation is, if you expected something else, let me know. Or here's what I've got, have someone to bounce ideas off of. But there's such a nicety if you can find that I'm going to try failing just a little bit and get some feedback. Or maybe it's not failing at all, but you are testing that boundary to find out did this work, or should I put more effort into this? I'm curious, do you have thoughts on that? How you're going to find that right optimization level? CHRIS: Not as specific to truly honing in on whatever the correct number is. The thing that I've been doing is I...this will sound complicated, but I wait until the last minute but a specific version of the last minute. So at most, I start working on it an hour and a half before the meeting. And these are, again, not particularly large presentations, and it's a recurring sort of thing. So it's sort of engineering talking about the work that we've done recently and trying to find the right level of detail and whatnot, so giving myself a smaller time window. I think that's enough time to tell the story and to find a meaningful way to tell the story and grab the screenshots and all of that, but it's constrained so that I don't over-optimize, over-edit, overthink. I'm using Deckset, which is a presentation tool that starts from a Markdown file. So it's just a Markdown file that I'm editing. That's great; that works really well. I do not twiddle with fonts. There's one theme that I use. It is white background with black text. That's it. And I think I've given myself deep permission to be the CTO that has a white background with black text and no transitions. I don't even go into presentation mode for it. I'm literally showing the UI of Deckset, and then just hitting the arrow to move between them. But the Chrome and the drop-down menu at the top is still visible because I want to see people's faces as I'm presenting. And I haven't figured out how to do that correctly on my computer. So I'm just presenting the window of Deckset. And I'm like, I have given myself permission to do all of those things, and that has been super helpful, actually. So that's a version of me negotiating what this means. Where I do invest the effort is trying to enumerate all of the things and then understand what is the story that I'm telling around the things and how do I get the message right for the collective audience? So, for a developer team, I would say much more nuanced technical things, for marketing folks, it would be at this end of the spectrum. I do lean on the old idea of, like, let us talk about it in the mindset of the user, so it's very much user-centric, but then some of the things that we're doing are important but invisible to the users. They're part of how we broadly build the platform that we need to, but they're completely invisible to users. And so, how do I then tell that story still with ideally a user-centric point of view? So that's where I do invest the time, and I give myself complete freedom to just grab screenshots, put black text on a white background, and then talk over it. STEPH: I love it. Because you made this comparison earlier, so now I'm thinking of a comparison of like TDD-driven presentations where it's like, what's the end goal? What's the assertion? What's the outcome that I want? And then backfilling from there. Or, in your case, you're talking about what's the story that I need to tell? What's the takeaway that I want people to have? So then you start there, and then you figure out what's the supplemental information that you need to provide to then get there. And the fact that you don't twiddle with fonts and all that stuff, I think you're already really on your way [chuckles] in terms of finding that right optimization of I need to present a clear and helpful message but not sink too much time into this CHRIS: Black text on a white background is very clear. So... STEPH: [laughs] If there are any designers listening to this, they might just be cringing to this conversation right now. [laughs] CHRIS: I actually wonder about what the...I know that dark mode is a thing that lots of folks care about. I'm thinking about the accessibility affordance of it now. I'm actually thinking through it now that I said it somewhat flippantly. I actually don't know what I'm talking about, but it was easy, and it wasn't a choice that I allowed myself to think about. So there we are. Mid-roll Ad Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: In my personal world, so Tim and I are moving. We're on the move. We are transitioning from South Carolina to North Carolina. So I think I may have shared a bit of this news, but Tim has acquired his first software developer job, which is just phenomenal. It is in North Carolina. He does need to be there in person for it. So we are currently selling our South Carolina house and then moving. It's not too far. It's like three and a half hours away to where we're moving in North Carolina because we're already pretty far in North and South Carolina. So yeah, there's always another box that needs to be packed. And there's always just something else that you forget, another thing that you want to take to Goodwill or try to give to a neighbor. It's a good way to purge. I will definitely say that every time you move, it's a good time to get rid of things. CHRIS: That is a very cup half-full point of view on it, but yeah, it feels true. STEPH: [laughs] It's true. I'm a very cup half-full person. For more technical news, for more client stuff that I've been working on, so I think the last time we chatted, I was sharing that we had this mysterious CI slowdown where we were going from CI builds taking around 25 minutes to spiking to 35, sometimes 45 minutes, and I have an update there. So we found out some really great things, and we have gotten it back down to probably more about 23 minutes is where the CI is running currently. As for the actual who done it, like what caused this specific slowdown, we got to a point where we were like, we're doing so much investigative work to understand exactly what caused this that it felt less helpful because at the end of the day, we really just wanted to address the issue. And so solving the mystery of exactly what caused this started to feel less and less meaningful because we're like, well, we want to improve this anyways. So even if we found that one line or something that happened that caused this, we want a bigger solution to this type of problem because then this could happen again like, someone else maybe adds one line or something happens, and things get thrown off balance, and then suddenly, we have a slowdown, and that just takes too long to investigate. So I don't have a concrete who done it answer for the slowdown. But we've learned a couple of things; one of the things that we learned is we're using parallel_tests to then split our tests across all of the CPUs that are then running the RSpec test. And we realized that we weren't actually splitting tests based on runtime data. So there are a couple of ways that paralleltests will let you divvy up your test, and two of those ways one is file size. So you can split the files based on the size of the file, or you can use info from the runtime log. So then paralleltests can be a little bit more intelligent about like, well, I know how long these files take, so I'm going to split it based on that versus just the size of the file. And we realized that we were defaulting and using the file size instead of the runtime even though we all thought we were using runtime. And the reason for this took a bit of source code diving because looking at the README for paralleltests; it looked like as long as we're passing in a file to the runtime log path, then paralleltests is going to use that runtime data. But then there's some sneaky-sneaky in there that I'll actually link to in the show notes in case anybody's interested. But if you are setting a particular flag and don't pass in another flag, then paralleltests is going to be like, cool, I'm going to portion out your test based on file size instead of the runtime. So we fixed that, or we updated that, and that has had a significant improvement for the test being split out more evenly. So we didn't have a CPU that was taking 25 minutes while the next CPU was only taking like 17 minutes. And paralleltests also provides some really helpful data that because we have that runtime log file, we could tell how long each CPU is running and how they're getting split. So the past couple of weeks, it's heavy measure, measure, measure, take all the data, create lots of graphs, understand what's happening, and then look for ways to then fix it. So figuring out how these files or how the tests were being distributed across, we had a number of graphs that were just showing us what's actually happening. So then we could track the improvement, so that was really nice. It was the measure twice and change something once [laughs], and then we got to see the benefit from it. For scaling the CI, so we are looking on adding more machines to then process tests. That has been really interesting because we're at the point where we are adding more machines, but if we add more machines, we're not going to speed up how quickly our CI processes everything. Because we are splitting tests based on file size and not by examples, we're always going to have this effect of a tentpole. So if we have a file that takes 10 minutes, that's the fastest we're ever going to get. So Joël and I are in discussions right now of where we still really want to understand what's the fastest we can achieve just by adding another machine or two versus are we at the point that, okay, scaling horizontally and adding more machines has been helpful, but we have reached the breaking point where we actually need to divvy out the tests at a smaller scale and have a queue approach? So then that way, we can really harness the power of then we don't have one file that takes 10 minutes, and we don't have to care either. So if somebody adds a test to a file and suddenly a file goes from 12 minutes to like...well, hopefully, they added more than one test. [laughs] But let's say it goes from 10 minutes to 15 minutes; we don't want to have to manage that and understand that there's a tentpole. We just want to be able to divvy out all the examples and then have a queue approach. That's probably going to be MVP two of this, but we're still waiting that out. But it's just been really interesting to realize that scaling horizontally really only takes you so far. Like, we've added one machine, maybe one more, so then we'll have three total. And then it's like, okay, that's great, but now we need to actually address this other bigger problem. CHRIS: I know we've talked about this in previous episodes, but I'm super interested to hear as you progress into the queue approach because that's something that's been top of mind for me for a while. I don't know if we've talked about it before specifically, but Knapsack Pro is the one thing that I'm available as a service that does this. Do you have other tools that you're looking at for that, or is this still in the exploratory phase? STEPH: Knapsack is still a top contender. There's also RSpec Queue; that's another one that we have in mind. Unfortunately, I really wish paralleltests let us do this, but paralleltests just doesn't quite offer that feature. And someone in the team, I think, even reached out to the maintainer of paralleltests, and they were like, "Yep, you're totally right. We're actually more focused in making sure that this works for everybody versus has specific features." And they gave a really nice thoughtful response, which we appreciated, so at least we could confirm that paralleltests won't do exactly the thing that we need. So yeah, RSpec Queue, Knapsack, I think those are the top two that I'm familiar with. CHRIS: Gotcha. I don't know if I've seen RSpec Queue before. I'm intrigued. So actually, an interesting thing happened. While I was away on vacation, one of the folks who just joined the team as one of their first steps joining the team, noticed that our CircleCI config wasn't actually taking advantage of the parallelism that we had configured; that's on me. I turned on parallelism and then never did anything with it, which is a complete waste. And so I was super happy to come back and saw that CI, which had been creeping up to six or seven minutes, had suddenly dropped back down to two to three minutes sort of thing. I was like, this is amazing. But now I'm at the point where our RSpec suite is spreading across the different, I think, it's like four different cores that we have available, but it's not doing it as efficiently as we would like. So I'm like, oh, okay, can we dial it up to 11? But I'm intrigued; I've only looked very much in passing at RSpec Queue literally now that you've mentioned it. But Knapsack Pro exists as a different service. And so, as far as I understand, the agent that's running is going to communicate and say, "Give me another test. Give me another test." But there needs to be some external process running and managing that queue. Does RSpec Queue do that? Somebody owns the queue, right? Who owns it? Do you understand how that works? STEPH: So I was definitely familiar with this. If you'd asked me a couple of weeks ago, when I was diving heavily into the queue work before then, we transitioned more into focusing on then adding new machines; I was very up to speed on this. So I may get a couple of things wrong, but my understanding is that RSpec Queue, you're going to manage your own queue. So you bring in the gem and then use something like Redis, so then you are in charge of that. And with Knapsack, then you are using their service to manage that queue. And then they have found ways to optimize around what if you can't reach their API or something; their service is down? And making sure that that doesn't impact your CI so then you can't still run your test just because you can't reach their queue somewhere. So that's my current understanding, RSpec Queue you own it, Knapsack they're going to own it. CHRIS: Gotcha. That makes sense. That about maps to what I was expecting, and so I wonder if I could use RSpec Queue. Now I'm going to have to go research that. But it's always nice to have new things to look at on this to go at ludicrous speed. That's what I'm going for. I want to get to ludicrous speed for our CI. STEPH: I like that name. I haven't heard of that speed. I feel like I have. I feel like you've dropped that before, [laughs] like you've used that. CHRIS: I don't know; quite possibly, I have. It's a Spaceball's reference. It's a throwback to days of old. STEPH: Well, then we may be investigating RSpec Queue together. Because yeah, Joël's and I goal for this week has been very much to figure out what's our boundaries with TeamCity? What are our boundaries with horizontal scaling? And I think we're both getting to that conclusion of like, okay, this has been good, it's helpful, but we really need to look into the queue stuff if we really want to see significant progress. Also, some of the stuff we're doing because we're pushing on it, we are manually splitting files. So if there's a file that has created this tentpole that's taking 10 minutes, but we know ideally most of the other files only take six minutes, then we are splitting that file, so then we have two spec files that are associated with the same class. And then using that as a way to say, okay, what would this look like? Let's say if this were better balanced. And that's also been pushing us in the direction of like, okay, this is fun, this is informative, but it's not sustainable. We don't want to have to keep worrying about splitting these files and doing this manually and pushing us towards that queue-based approach. MIDROLL AD: And now a quick break to hear from today's sponsor, Studio 3T. When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy. And now, there's Studio 3T Free, a free edition of Studio 3T which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with Mongo DB, SQL, Oracle and Sybase. You can start today by downloading Studio 3T Free, which also includes a 30 day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial head to studio3t dot com forward slash free. That's studio dot com forward slash free. But shifting gears just a bit, we have a listener question. So this person wrote in, "I have listened and loved your podcast for many years dreaming of getting a job with people half as thoughtful and intentional as you, and finally it happened. I have my first junior dev job, and my co-workers and bosses are all super awesome. Up until now, I've been flying solo. And in my new job, I've been finding it very unsettling to resolve merge conflicts. As careful as I am to comb through the conflict and contact the other developer if needed, I feel like I am covering my eyes and crossing my fingers whenever I select the resolve conflict button. Is there some type of process or checklist I could rely on? Is it normal to have such a high fear factor with a merge conflict? Any advice or maybe just a bit of been there felt that way...?" All right. So one, that's fabulous, congratulations on the new job. That's very exciting. I think I've voiced this many times, getting your first junior dev job is so hard, and so I'm so excited when it works out for people, and they get there. And then, for the merge conflict, I have thoughts. Chris, do you want to start? Shall I start? How are you feeling? CHRIS: Why don't you start? Well, actually, I'm going to add some pre-commentary, and then I think you should lead into our actual answer. But first, I just want to say a deep thank you to this listener for sending in the question. Again, we really love getting these questions. And also, thank you for the very kind words. To be clear, listener, if you're going to send in a question, you don't have to say very kind words, but they are really wonderful to hear and especially to hear if we had any part in helping this person feel more comfortable getting into that first dev role and having an idea of what maybe a good version of that could look like. Additionally, I really love the shape of this question because it gets into the people stuff and the tech stuff, so I'm super excited about this question. Actually, both Steph you and I responded very quickly to this one. And so it really did catch our attention because I think it crosses that boundary in an interesting way that I think is sort of The Bike Shed space in the world. But to that end, you did reply first in our email chain. So I think you should start, and then I'll follow on after that. STEPH: I should also check with you. Wait, so you don't have a filter on your email that's like kind words only to The Bike Shed, and then you filter out anything that's negative? CHRIS: I have a sentiment analysis, and if it's even neutral, it gets sent straight to the trash, only purely positive. No, constructive feedback is welcome too. We would love to hear that. Well, love is a strong word. We would accept it into our inboxes and then deal with it, but yeah. STEPH: [laughs] It will be tolerated. Must require at least three hearts in all emails; just kidding. [laughs] CHRIS: Are you kidding? I'm counting them now, and I see a lot of hearts in our emails. [laughter] STEPH: Merge conflicts. So is it normal to have such a high fear factor with a merge conflict? I'm going to say absolutely. Resolving a merge conflict can be really tricky and confusing. And I think; frankly, it's something that comes with just time and practice where then you start to feel more confident. As you're resolving these, you're going to feel more comfortable with understanding what's in the branch and the code changes that you're pulling in versus something that you need to keep on your side. So I think over time, that fear will subside. But I do think it's totally normal for that to be a very scary thing that then takes practice to become accustomed to it. As for if there is some type of process or checklist, I don't know of a particular checklist, but I do have a couple of ideas. So one of the things that I do is I will often push my code to whatever management system I'm using. So if I'm using GitHub, then I'm going to push up my branch because then, at least that way, someone has a copy of my work. So if I do something and I completely botch it locally, I know I can always reset to whatever it is that I pushed up to GitHub, so then that way, I have more freedom to make mistakes and then reset from there. So that is one idea is just put it somewhere that you know is safe, so that way you now have this comfortable sandbox to then make mistakes. The other one is run the test. So hopefully, the application that you're working with has tests that you can trust; if not, that could be another conversation. But if they do have tests, then you can run those, and then hopefully, that would let you know that if you have left something in, like maybe you left a syntax error, or maybe you removed some code that you shouldn't have because you weren't sure, then those tests are going to fail, and they'll let you know that something went wrong. And you can run those while you're still in the middle of that merge conflict as long as you've addressed like...well, no, if you haven't addressed syntax errors, that's still a time that you can run it, and it's going to let you know that you haven't caught all of the issues yet. So you don't have to wait till you're done to then go ahead and run that. A couple of other ideas, practice. So go ahead and create your own merge conflicts on purpose. So this is something that I think is really helpful because it will teach you, one, what causes a merge conflict? Because now you have to figure out how to create one, and then it will help you become comfortable because you're in a completely safe place where you have made up the issue, and now you're having to resolve that, so it'll help you become more confident in reading that merge conflict message. And then last but certainly not least, grab a buddy so if you are just feeling super nervous. Anytime I'm doing something that I just feel a little nervous about, then I just ask someone like, "Hey, would you look over my shoulder? Would you pair with me while I do this?" And I have found that's incredibly helpful because it eases some of my fear. I've got someone else that is also looking through this with me. But I also find it really helpful because then it encourages that person to be like, hey, if they're ever in a spot that they need to pair, I want them to know that they can also reach out to me and have that same buddy system. I guess that's my checklist. That's the one I would create. How about you, Chris? What do you think? CHRIS: Well, first, I just want to say that basically everything you said I 100% agree with, and purposely I think was great that you actually replied to the email first and that you're saying those things first because I think everything that you said is true and is foundational. And it's sort of the approach that I would definitely recommend taking as well. My answer, then adding on to that, has to do with how I've approached learning about this space in my own career. To name it, to answer the core question, is it reasonable to be scared of this? Yes, Git is confusing. Git is deeply confusing. I absolutely love Git. I have spent a lot of time trying to understand it, and in understanding it, I've come to love it. But it's only through deep effort that I've gotten to that place. And actually, the interface, the way that we work with Git on a day-to-day basis, particularly the command line is rough. I'm going to say, what does Git checkout do? Well, it does just about everything, it turns out. That command just does all of the stuff, and that's too much. It's, frankly, the UI for Git, specifically the command-line user interface; the commands that we run to manipulate the Git history are not super intuitive. But it turns out if you pop open the hood, the object model underneath the core way that Git stores your code is actually very simple. I find it's very easy to understand, but I, unfortunately, have found that I can't understand it without dropping down to that level. And so, in my own adventures, I kind of went deep on this topic a couple of years ago, and I created a Vim plugin because obviously, that's the best way to encapsulate your knowledge about Git, and so I created a plugin called Vim Conflicted. I don't necessarily recommend the plugin. It's fine if you want to use it. I don't do a great job of maintaining my plugins at this point, to be honest. But there was a weekend where I was trying to understand the world of Git and merge conflicts in particular, and it was really sort of fighting me. And as I started to understand it better, there's a little diagram that I drew on the README that I think is probably the most interesting artifact from it. But it's this idea that there are actually four files, four versions of a given file involved in any merge conflict. And that realization shifted my thinking a good amount. And then as I started to think about that, I was like, oh, okay, and then I want to see this version of it, and this version of it, and this combination, and the diff between these two, and that was super helpful for me. More generally, I also made a course on Upcase about Git as I tried to understand it better. And there are two particular videos from the middle of the course named the Git Object Model and Object Model Operations. And again, those two videos deal with popping the hood on Git, looking inside it, and what actually is happening to your code as you perform different Git operations. One of the wonderful things about Git is it is immutable. So you're never going to destroy your Git history if you've committed. So one of the rules that I have is just always be committing, never worry about committing. If you've committed, you can always get back to that version. You would have to try very hard to destroy committed code in Git. It's the things that you do when you haven't yet committed the code that are dangerous. So commit the code, like you said, Steph, push that up to GitHub, so you have a backup of it. You will have a backup locally as well, and that's a thing that you can come to be more comfortable with. But then, from there, there's actually a lot of room to experiment and play around because there's a ton of safety in the way that Git stores the code. You do have to know how to get at it, and that's the unfortunate and tricky part. But I think, again, to sort of summarize, yes, this is confusing. Your feelings are absolutely valid and totally grounded, but it is also knowable, is what I would say. And so, hopefully, there are a couple of breadcrumbs that we've laid there in how you might go about learning about it. But yeah, find a buddy, watch a video or two, and give it a try. This is definitely a thing that you can get there but totally reasonable that your first approximation is this is confusing because it sure is. STEPH: I often forget that Git has that local copy of my code, so I'm so glad you mentioned that. And then yeah, I saw when you linked to Vim Conflicted. The diagrams are great. I had not seen these before. So yeah, I highly recommend folks take a look at those because I found those very valuable. CHRIS: In that case, it's a white background, but I allowed myself to use some colors in the little images to help differentiate the different pieces. And it's an animated diagram, so it's really a high bar for me. [laughs] STEPH: So now the question is, did you go too far? Have you over-optimized? [laughs] CHRIS: I'm going to be honest; it was a weird weekend. STEPH: [laughs] Well, I don't think you've over-optimized. I do think it's wonderful. And I think this is definitely a reference that I'll keep in mind for folks whenever they're learning about merge conflicts or just want to get more knowledgeable about them. I think these diagrams are fabulous. CHRIS: Well, thanks. Yeah, I hope...they frankly were a labor of love, and the course is three and a half hours of me rambling about Git, so hopefully, it's useful to folks. If anything, it was super useful to me because my understanding of Git was deeply crystallized in making that course. But I do hope that it's useful to other folks. And particularly those two videos that I highlighted, I think are the ones that have been most impactful for me in terms of how I think about working with Git and getting comfortable with it. STEPH: Do you still receive emails every now and then from people, or maybe they are tweets from people that are like, "Hey, I watched one of your videos and found it really helpful." I feel like I still see that every now and then where people are just commenting on like, they watched some of the content that you created for Upcase a while back, and I think that's really cool. I'm curious if you still see that. CHRIS: I do, yeah, from time to time. It is absolutely wonderful whenever I hear that. Again, listener, do not feel the need to send me anything, but it is nice when I get them. STEPH: It does seem like I'm fishing for compliments now. [laughs] CHRIS: It does seem like that. So I want to be clear that's not what's going on here. But it is nice because I do actually forget that they're out there. But a lot of the stuff that I produced for Upcase, in particular, I tried to do more timeless stuff, so like the Vim content was really about how Vim works in a deep way. And the tmux course and the Upcase course...or the tmux course, the Git course. I look back at them, and a couple of little syntactic things have changed. But I'm still like, yeah, I agree with me from six years ago or whatever it was. Oh, that's a weird number to say, and I think is honest. It's fine. I'll just be over here. [laughs] STEPH: [laughs] That's helpful to hear, though, because that's always one of my fears in creating content. It's like, I don't know, it's okay if it's more opinionated and I change my mind and disagree with my past self. But it's more like, yeah, keeping up with is this still accurate? Is this still reflective of the times? And then having to keep that stuff updated. Anywho, that's a whole big thing, content creation. CHRIS: Content creation, but there's a parallel to it that many folks will not be creating content, and I think that's a very fine and good way to go about progressing on the internet. But there's a parallel to it in learning that I think is useful. I, at this point, will typically lean in if there is something in the SQL layer that is fighting me. I have never found effort spent trying to better understand the structured query language to be wasted time. Similarly, Git is one of those tools that is just so core to the workflow that it felt very worth it to me to spend a little bit of extra time to get to a deeper level of comfort with it, and I have not regretted one minute of that. Vim and tmux are pretty similar because they're such core tools for me. But React, I would not call myself a deep expert of React. I follow some of the changes that are happening but not as deeply, and I'm not as worried about it. And if I'm like, I don't know how to do this thing, should I spend two hours learning about it or not? With frameworks and tools that have not been part of my toolset for as long, I will spend less time on them. And I think that the courses that I produced on Upcase mirror that. They're the things that I'm like; I feel very true about these things versus other stuff. Maybe it was in a weekly iteration episode or something like that. But that very much mirrors how I think about learning as well. What are the things that I'm going to continually invest in versus what are the things that I'll sort of keep an eye on from a distance but not necessarily invest as much time in? STEPH: There's a particular article that you're making me think of as we're talking about content creation and, as you mentioned, finding the things that you always find value in investing in. There's a wonderful blog post that was recently posted on the thoughtbot blog by Matheus Richard, and it's called The Opportunity Will Find You. And it made me think a lot about what you're talking about, find the things that you're excited about, find the things that you think are a good investment and just go ahead and lean into it. And it's okay if maybe that's not the thing that you're using currently at your work, but if it's something that gets you excited, then go ahead and pursue that. So in this article, for example, Matheus uses the example of learning Rust, and that's something that he's very excited about and wants to learn more about. And then there's another one where he started looking into crafting interpreters. And then that has actually led to then some fruitful work around creating custom RuboCops because then he had more knowledge around how the code is being interpreted so then he could write custom RuboCops. So yeah, plus-one to finding the things that give you energy and joy and leaning into that and investing in it. And if you share it with the world, that's fabulous, and if you don't, then keep it for yourself and enjoy it, whatever makes you happy. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Reporting is often the last part of accounting or business projects. Unfortunately, most businesses overlook the complexity of their reporting needs and underestimate their requirements. This causes an issue when it comes time to pull a sales report or calculate taxes. Accountants are often stringing together multiple spreadsheets to back into the information they need. This results in frustration from manual procedures, clerical errors in preparation, and poor efficiency in the office. myDBR can resolve all these problems and provide outstanding reporting right out of the box!  myDBR turns data from MySQL, MariaDB, Microsoft SQL Server, and Sybase databases into usable actionable information. This tool can be used for personal reporting or scaled up to enterprise business intelligence systems. Reports can be accessed from applications, portals, and mobile devices. myDBR integrates easily with any environment and allows for monitoring of users and data. Data can even be directly edited from within myDBR reports. This application is packed with easy-to-use functionality. From accounting reporting to customer support tickets and more, this tool can do it all! Please join us on how you can eliminate all your organizational reporting headaches!  Lastly, don't forget to check out part two of this course where we talk with the folks behind myDBR. We will learn about their favorite features, functions, and capabilities. We will also get knowledge on where the application will be going in future releases. Don't miss this one!  Are you a CPA?? Are you a Financial Professional?? Earn CPE Credits for Today's Podcast. Check out https://cpe.cx/dbr1/. Take a quick 5 question quiz and get your certificate today. Super Easy!  Presented by Stephen M. Yoss, CPA, MS (https://yoss.io) Produced by Alicia Yoss & Alanna Regalbuto Graphics By Flaticon.com and iStock Music by Bensound.com Education and Compliance By K2 Enterprises (https://k2e.com) Copyright. All product names, logos, and brands are the property of their respective owners. All company, product, and service names used on this website are for identification purposes only. The use of these names, logos, and brands does not imply endorsement. Educational Use Only. The information presented in this presentation is for educational use only. The presenter will make specific recommendations, but the participant is highly recommended to do their own due diligence before making any investment decision.

Had an amazing conversation conversation with Dr. Babak Hodjat, the CTO of Evolutionary AI at Cognizant. Babak is a deep thinker, researcher and a practical entrepreneur and we discussed evolutionary computing, how to use AI to optimize for multiple outcomes, Data lakes and Lake houses, AI winters and the most important work in Deep Learning today. I hope you enjoy this conversation as much as I did.   Bio: Babak Hodjat (https://en.wikipedia.org/wiki/Babak_Hodjat) is the CTO for AI at Cognizant where he leads a team of developers and researchers bringing advanced AI solutions to businesses. Babak is the former co-founder and CEO of Sentient, responsible for the core technology behind the world's largest distributed artificial intelligence system. Babak was also the founder of the world's first AI-driven hedge-fund, Sentient Investment Management. Babak is a serial entrepreneur, having started a number of Silicon Valley companies as main inventor and technologist. Prior to co-founding Sentient, Babak was senior director of engineering at Sybase iAnywhere, where he led mobile solutions engineering. Prior to Sybase, Babak was co-founder, CTO and board member of Dejima Inc. Babak is the primary inventor of Dejima's patented, agent-oriented technology applied to intelligent interfaces for mobile and enterprise computing – the technology behind Apple's Siri. Babak has published many papers in the fields of Artificial Life, Agent-Oriented Software Engineering, and Distributed Artificial Intelligence, and has 31 granted or pending patents to his name. He is an expert in numerous fields of AI, including natural language processing, machine learning, genetic algorithms, distributed AI, and has founded multiple companies in these areas. Babak holds a PhD in Machine Intelligence from Kyushu University, in Fukuoka, Japan. Reach Babak at https://www.linkedin.com/in/babakhodjat/

Mark Hanson is the Co-founder of Bricoleur Vineyards, a place that brings people together through their vast array of activities such as wine tastings, food and wine experiences, acres of gardens, and even fishing. Mark purchased a Russian River Valley vineyard with his wife and daughter, and in 2017 transformed it into Bricoleur. Aside from being a lover of wine, Mark has over 30 years of experience in the software industry and is still on the Strategic Advisory Board at Genstar Capital. He has held previous executive positions at Siebel Systems, Visigenic Software, and Sybase. In this episode: If you're a wine enthusiast, you've probably attended many wine tasting experiences. But what if there was an all-inclusive winery that has fishing, bocce ball, locally grown produce, and tasty wine? Meet Mark Hanson of Bricoleur Vineyards, who is changing the game of wine tasting experiences. After a successful career in the software industry, Mark, along with his wife and daughter, decided to purchase a vineyard in the Russian River Valley in Sonoma County, CA. They officially opened Bricoleur in 2017 and have produced six original wines — and counting. Mark is here to share his journey and recommend some food and wine pairings along the way. On this exciting episode of the Legends Behind the Craft podcast, Drew Hendricks talks with the Co-founder of Bricoleur Vineyards, Mark Hanson. They discuss all Bricoleur has to offer, how to craft a unique visitor experience, the process of creating new wines, and much more. You don't want to miss this jam-packed episode!

Patrick Lencioni explores so many leaders fall short--and how to resolve it.You'll Learn:1) The mentality that separates great leaders from the rest2) Why you shouldn't be afraid of micromanaging3) How leaders can have more joyful difficult conversationsAbout Patrick:Pat is the founder of The Table Group and the author of 11 books which have sold over 5 million copies and been translated into more than 30 languages. The Wall Street Journal called him "one of the most in demand speakers in America." He has addressed millions of people at conferences and events around the world over the past 15 years. Pat has written for or been featured in numerous publications including Harvard Business Review, Inc., Fortune, Fast Company, USA Today, The Wall Street Journal, and BusinessWeek.As CEO, Pat spends his time writing books and articles related to leadership and organizational health, speaking to audiences interested in those topics and consulting to CEOs and their teams.Prior to founding The Table Group, Pat worked at Bain & Company, Oracle Corporation and Sybase. Pat lives in the Bay Area with his wife and four boys.Patrick's book: The AdvantagePatrick's book: The Motive: Why So Many Leaders Abdicate Their Most Important ResponsibilitiesPatrick's podcast: At The Table with Patrick LencioniPatrick's website: TableGroup.comResources mentioned in the show:Personality: Alan MulallyBook: Brother Odd: An Odd Thomas Novel by Dean KoontzPrevious episode: 302: Curing the Under-Management Epidemic with Bruce TulganThank you Sponsors!Care.com/Awesome. Save 30% on a premium membership to find the perfect caregiver for your child, parents, and home.View transcript, show notes, and links at http://AwesomeAtYourJob.com/ep552 See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.