Podcasts about senior developers

Microsoft's Power Plattform bietet mit Power Apps einen integrierten Service, um Applikationen zu erstellen. Markus Franz ist Senior Developer und Super User im Microsoft Community Form und gibt uns als Experte für diesen Bereich einen Einblick in seine tägliche Arbeit und Beispiele, mit denen er bereits zu tun hatte. Themen in In dieser Folge: Grundlagen zu Copilot Studio, Power Apps, Power Pages, Power Automate Canvas App vs. Model-Driven Apps Azure AI Builder Low Code vs. Pro Code Beispiel 1: Negative E-Mails erkennen und delegieren Beispiel 2: AI-basierte Reisekostenabrechnung LinkedIn-Profil von Markus Franz: https://www.linkedin.com/in/markus-franz-435759278/ LinkedIn-Profil von Daniel: https://www.linkedin.com/in/drohregger/

I build UI and UX for a company using React. What should I do next? How do I get to the senior level? Stop Being a Junior Go down to level up EpicReact.dev Build React Hooks I'm a React dev... What now?

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

Send us a textWithout a clear path from junior developer to senior, most developers fall into the coding trap:You double down on your current programming language to become an "expert"You add more tools to your tool belt like a new, more impressive programming language (Rust anyone?)You obsess over code quality and writing error free codeYou wonder why you haven't been promoted yetPlot twist: I am you.I made all these mistakes and have since gone on to be a senior at multiple companies even though I've rarely been the best coder on any team.As an engineering manager, I had the privilege of promoting developers to senior and the awkward duty to share with developers why there were NOT getting promoted.Let's break down how you can shorten your path to senior developer, step by step.Shameless Plugs

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

In this episode, Oliver Cronk is joined for a discussion on observability by Scott Rowan, Senior Developer at Scott Logic, and Daniel Gomez Blanco, Principal Engineer at Skyscanner and a member of the Open Telemetry Governance Committee.   The conversation explores what observability means in modern distributed software architectures, how it differs from traditional monitoring, and the challenges of implementing observability at scale. The discussion touches on practical aspects of implementing observability and how this approach can lead to faster problem detection and resolution, as well as cost savings by reducing the volume of less useful data collected.   The rise in popularity of observability has gone hand in hand with the rise of microservices and event-driven architectures. But although it's a relatively new kid on the block, is observability hyped or a necessary evolution in managing modern software systems? Links from this episode What is Observability? – The New Relic perspective What is Observability? – The Dynatrace perspective OpenTelemetry website OpenTelemetry introduction at CloudNativeCon

In this episode of PodSpot, Jon Dean, HubSpot Development Team Manager and Chris Brown, Senior Developer here at Karman Digital discuss the benefits of using HubSpot for website management. They highlight HubSpot's built-in security and maintenance, which allow businesses to focus on content creation without worrying about technical issues. The platform's scalability, marketer-friendly interface, and recent AI-powered content creation tools are key features that make it suitable for businesses of all sizes. The conversation also covers advanced features like smart content, embedded content versatility and HubDB for sophisticated data management. The recent updates to HubSpot's Content Hub, including AI tools for blog writing, image generation and translations, demonstrate its comprehensive capabilities. These tools enhance productivity and accessibility, offering a powerful, all-in-one solution for managing and optimising online presence for businesses of all sizes.   03:16 - 41:10 03:16 - HubSpot's advantages in website management and security 06:04 - Who HubSpot is suitable for 14:22 - Advanced features and smart content 21:43 - Content Hub and AI tools 37:12 - HubDB and its applications 41:10 - Reporting capabilities in HubSpot   Want to learn more about HubSpot? Visit our website: https://www.karman.digital/  Follow us on LinkedIn Listen on Spotify Listen on Apple Podcasts

Hunter's out on tour this week which means Matt needed a new friend! Good for him he works with some pretty cool folks, including Nick Brachmann! Nick is a Senior Developer at Leder Games and is responsible for the upcoming Ahoy: New Horizons expansion. It more than doubles what is possible in Ahoy and Matt has been playing a lot of it recently. Let's talk game development, creativity, and fostering strategic depth! Also MAPS. Music provided by Ben Prunty. Find more at benpruntymusic.com or benprunty.bandcamp.com Additional Music and Sounds by Brian Kupillas. https://wanderinglake.bandcamp.com/ To learn more about our Discord, Patreon, Merch, and more, visit https://spacecatspeaceturtles.com/

We're excited to have Jenny Jarzabski, Senior Developer at Paizo, joining us to discuss "Unionization in the Video Game Industry." Jenny brings a wealth of experience and insights into the topic, having played a pivotal role in advocating for unionization within the game industry. Throughout our conversation, we'll delve into various aspects of unionization and its impact on game developers. Jenny will share her firsthand experiences, shedding light on her job responsibilities at Paizo and the motivations behind the decision to unionize. We'll explore the significance of solidarity in the workplace and delve into the bargaining process involved in establishing a union. Furthermore, Jenny will provide valuable insights into the role of a union steward and discuss the potential downsides of being in a union, offering a balanced perspective on the topic. For those interested in unionizing their workplace, Jenny will offer practical advice on the first steps to take and highlight the importance of collective action in advocating for workers' rights. Additionally, Jenny will share her excitement about upcoming releases in the tabletop gaming industry, giving us a glimpse into the innovative projects she's been working on at Paizo. Stay connected with Jenny Jarzabski on social media: Twitter: https://twitter.com/spaceprincess_j LinkedIn: https://www.linkedin.com/in/jennifer-jarzabski/ Join us as we explore the crucial topic of unionization in the video game industry and gain valuable insights from Jenny's extensive experience and advocacy efforts. #IndieGameBusiness #Unionization #VideoGameIndustry #JennyJarzabski #Paizo #GameDevelopment #WorkersRights #Solidarity #UnionSteward #CollectiveAction #TabletopGaming #Starfinder #Pathfinder --- Support this podcast: https://podcasters.spotify.com/pod/show/indiegamebusiness/support

FYI! This is part TWO in this series. The First part is hosted over on No Quest for the Wicked's feed! This week we are breaking from the main campaign for a very exciting partnership with our friends at No Quest for the Wicked and Jenny Jarzabski, the Senior Developer for Starfinder at Paizo! Get a look at the new 2e rules in action, featuring the changes to Solarian, Mystic, Envoy, and Operative. Support our show on Patreon!Call to Action:Find and call your representatives and be heard (US)Find and call your members of Parliament and be heard (Canada)Find and call your members of Parliament and be heard (UK)

Progressing through your web development career is unique depending on the companies you decide to work for, but there are some common positions that companies will use to help guide their promotion process. These positions include junior developer, developer (intermediate), senior developer, tech lead, and staff engineer. Each one of these positions will have a unique flare depending on who's setting up the teams but in general as you climb the ladder through them you'll collect more cash, more responsibility, and slowly transition to less code/more management. In this episode Matt and Mike discussed the common promotions that web developers progress through and how they can vary company to company. Show Notes: https://www.htmlallthethings.com/podcasts/junior-developer-vs-senior-developer Learn with Scrimba - https://scrimba.com/?ref=htmlallthethings

Jared Parsons, the Principal Developer Lead on the C# Compiler Team. Everybody tuning in probably uses his code on a day-to-day basis! Jared started at Microsoft 20 years ago as a Developer; moved on to become a Senior Developer; then the Principal Developer on Midori OS; and most recently, the Principal Developer on the C# Compiler Team, which he has been with since 2014.   Topics of Discussion: [3:14] Jared talks about his twisty career path. [5:29] What does designing a programming language look like? [6:18] The two features in C#. [10:30] The C# language design process. [14:09] How we get from ideas to designs and implementations. [16:02] Jared recommends resources to learn more. [17:34] Jared's favorite convention for all the member types. [18:20] Primary constructors. [24:21] Is the entire compiler open source? [25:28] Thinking like a customer and pushing on the tools if needed. [30:33] How the process has changed over the years. [32:41] Jared's favorite testing unit.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! Jared Parsons on DevOps on the C# Compiler Team: Ep #53 Roslyn Github Roslyn Analyzers Github C# Language Github Jared on LinkedIn   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Do you agree with Dr Chuck? That this is the most important programming language you need to learn, and the language you shouldn't use in the real world (in most cases). You need to learn C if you're serious about becoming a senior developer. // David's SOCIAL // Discord: discord.com/invite/usKSyzb Twitter: www.twitter.com/davidbombal Instagram: www.instagram.com/davidbombal LinkedIn: www.linkedin.com/in/davidbombal Facebook: www.facebook.com/davidbombal.co TikTok: tiktok.com/@davidbombal // MY STUFF // https://www.amazon.com/shop/davidbombal // SPONSORS // Interested in sponsoring my videos? Reach out to my team here: sponsors@davidbombal.com // MENU // 00:00 - Coming up 00:48 - The most important programming language 03:25 - The successor to C 04:44 - Dr. Chuck's free C course // C Programming for Everybody 09:07 - What should be your first programming language // Python for Everybody 10:45 - Object Orient Programming 14:32 - "Stealing" The C Programming Language book // Interview with Brian Kernighan 19:30 - The history of C and C++ 25:29 - The history of Python 26:58 - The path to becoming a master programmer 30:15 - Dr. Chuck's next course // Hardware for Everybody 32:29 - Free and available Dr. Chuck courses 36:33 - Where to get started 38:36 - When to use C 39:04 - Which programming language to learn next 41:15 - Learn different programming languages 42:25 - How AI/ChatGPT changes coding 51:20 - ChatGPT vs college essays 54:12 - The future of AI // Is programming still worth it? 57:49 - Visiting students around the world 01:00:22 - Conclusion c rust c vs rust c course free c course dr chuck dr chuck master programmer #c #rust #drchuck

En este episodio nos sumergimos en el fascinante mundo de ser un desarrollador senior. Vamos más allá del código para hablar sobre el pensamiento y el proceso detrás de la programación. ¿Qué significa realmente ser un profesional en este campo? Acompáñanos en una charla amena donde exploramos la importancia de documentar, estandarizar y, sobre todo, compartir nuestras experiencias en el desarrollo web

Topics covered in this episode: Granian pytest 8 is here Assorted Docker Goodies New GitHub Copilot Research Finds 'Downward Pressure on Code Quality' Extras Joke Watch on YouTube About the show Sponsored by us! Support our work through: Our courses at Talk Python Training The Complete pytest Course Patreon Supporters Connect with the hosts Michael: @mkennedy@fosstodon.org Brian: @brianokken@fosstodon.org Show: @pythonbytes@fosstodon.org Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesdays at 11am PT. Older video versions available there too. Michael #1: Granian via Andy Shapiro and Bill Crook A Rust HTTP server for Python applications. Granian design goals are: Have a single, correct HTTP implementation, supporting versions 1, 2 (and eventually 3) Provide a single package for several platforms Avoid the usual Gunicorn + uvicorn + http-tools dependency composition on unix systems Provide stable performance when compared to existing alternatives Could use better logging But making my own taught me maybe I prefer that! Originates from the Emmett framework. Brian #2: pytest 8 is here Improved diffs: Very verbose -vv is a colored diff, instead of a big chunk of red. Python code in error reports is now syntax-highlighted as Python. The sections in the error reports are now better separated. Diff for standard library container types are improved. Added more comprehensive set assertion rewrites for comparisons other than equality ==, with the following operations now providing better failure messages: !=, =, . Improvements to -r for xfailures and xpasses Report tracebacks for xfailures when -rx is set. Report captured output for xpasses when -rX is set. For xpasses, add - in summary between test name and reason, to match how xfail is displayed. This one was important to me. Massively helps when checking/debugging xfail/xpass outcomes in CI. Thanks to Fabian Sturm, Bruno Oliviera, and Ran Benita for help to get this release. Lots of other improvements See full changelog for all the juicy details. And then upgrade and try it out! pip install -U pytest Michael #3: Assorted Docker Goodies OrbStack Say goodbye to slow, clunky containers and VMs OrbStack is the fast, light, and easy way to run Docker containers and Linux. Develop at lightspeed with our Docker Desktop alternative. Podman Podman is an open source container, pod, and container image management engine. Podman makes it easy to find, run, build, and share containers. Manage containers (not just Podman.) Podman Desktop allows you to list, view, and manage containers from multiple supported container engines* in a single unified view. Gain easy access to a shell inside the container, logs, and basic controls. Works on Podman, Docker, Lima, kind, Red Hat OpenShift, Red Hat OpenShift Developer Sandbox. CasaOS Your Personal Cloud OS. Community-based open source software focused on delivering simple personal cloud experience around Docker ecosystem. Also have the ZimaCube hardware (Personal cloud. Re-invented.) Brian #4: New GitHub Copilot Research Finds 'Downward Pressure on Code Quality' David Ramel Regarding “…the quality and maintainability of AI-assisted code compared to what would have been written by a human.” Q: "Is it more similar to the careful, refined contributions of a Senior Developer, or more akin to the disjointed work of a short-term contractor?" A: "We find disconcerting trends for maintainability. Code churn -- the percentage of lines that are reverted or updated less than two weeks after being authored -- is projected to double in 2024 compared to its 2021, pre-AI baseline. We further find that the percentage of 'added code' and 'copy/pasted code' is increasing in proportion to 'updated,' 'deleted,' and 'moved 'code. In this regard, AI-generated code resembles an itinerant contributor, prone to violate the DRY-ness [don't repeat yourself] of the repos visited." Extras Brian: Did I mention pytest 8? Just pip install -U pytest today And if you want to learn pytest super fast, check out The Complete pytest Course or grab a copy of the book, Python Testing with pytest Michael: I'd like to encourage people to join our mailing list. We have some fun plans and some of them involve our newsletter. It's super private, no third parties, no spam and is based on my recent Docker and Listmonk work. Big release for Pydantic, 2.6. New essay: Use Custom Search Engines Way More Joke: Pushing to main Junior vs Senior engineer

(Video Podcast available on Spotify and Youtube)In this 8th episode of "The Frontend Masters Podcast," Marc interviews Jem Young, a seasoned software engineer and engineering manager at Netflix. We talk about the evolution of frontend development, teaching technical skills, and the impact of emerging technologies like AI and quantum computing on our industry. Jem shares his journey from organizing college LAN parties to his tenure at Netflix, emphasizing the importance of public speaking and communication in tech roles. This episode will give you insights on navigating your career and enhancing your skills. Check out Jem Young's Frontend Master's courses here: https://frontendmasters.com/teachers/jem-young/ Check out Jem Young's Frontend Master's courses here: https://frontendmasters.com/teachers/jem-young/ Find Frontend Masters Online: Twitter: ⁠https://twitter.com/FrontendMasters⁠ LinkedIn: ⁠https://www.linkedin.com/company/frontend-masters/⁠ Facebook: ⁠https://www.facebook.com/FrontendMasters⁠ Instagram: ⁠https://instagram.com/FrontendMasters⁠ About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! ⁠https://frontendmasters.com/

Christopher Brown, Senior Developer of Business Development with Calgary Economic Development, joins Calgary NEXT hosts David Wallach and Tara McCool, to discuss the exciting and forward-looking business in the Calgary community.

In this episode of Whiskey Web and Whatnot, hosts RobbieTheWagner and Charles William Carpenter III invite Clark Sell onto the show. Clark, the founder of 'THAT Conference' and 'Unspecified', talks about the genesis of the conference, the current state of tech, and his use of artificial intelligence services likeGPT-3 and DALL-E. The hosts and Clark also try out a new whiskey, discuss football and their disdain for certain programming languages. Tune in to hear about the intersection of tech and whiskey, and get some insights into the future of AI and the tech industry. Key Takeaways [00:34] - Guest Introduction: Clark Sell [02:05] - Whiskey Tasting Session [07:11] - Hot Takes: Tech Debates [17:08] - The Journey of That Conference [23:45] - The Future of Tech and Conferences [31:13] - The Reality of Being a Senior Developer [31:26] - The Challenges of Job Hunting in Tech [31:52] - The Impact of AI on Tech Jobs [33:01] - The Shift to Remote Work [34:05] - The Debate on Return to Office [34:37] - The Rise of Online Personalities in Tech [35:07] - The Influence of Social Media on Tech Careers [35:42] - The Role of In-Person Interactions in Tech [36:35] - The Controversy Around React [37:30] - The Evolution of Web Development [38:07] - The Debate on HTML as a Programming Language [39:37] - The Impact of AI on Content Creation [41:07] - The Influence of Cryptocurrency [52:17] - The Role of AI in Education [54:43] - The Future of AI in Content Generation [58:37] - The Importance of Community Involvement in Tech Links Clark Sell Twitter Clark Sell LinkedIn THAT Conference Unspecified Connect with our hosts Robbie Wagner Chuck Carpenter Subscribe and stay in touch Apple Podcasts Spotify Google Podcasts Whiskey Web and Whatnot Promos Whiskey Web and Whatnot Merch Enjoying the podcast and want us to make more? Help support us by picking up some of our fresh merch at https://whiskey.fund/⁠. --- Send in a voice message: https://podcasters.spotify.com/pod/show/whiskey-web-and-whatnot/message

How is AI being used at the edge, and what possibilities does this create for businesses? In this episode, host Bill Pfeifer sits down with the co-authors of the book AI at the Edge, Jenny Plunkett, Senior Developer Relations Engineer and Daniel Situnayake, Head of ML at Edge Impulse. They discuss how to determine which problems can actually be addressed through AI at the edge, how to think about effective AI, and unexpected use cases in generative AI and synthetic data generation. Plus, they cover how AI can support data distillation efforts and how to build teams that can successfully navigate this landscape. ---------Key Quotes:“We're going to be using generative AI to help us build a synthetic data set to train other AI models to deploy to edge devices.” - Jenny“One of the things that's really cool about synthetic data and using generative AI for that, is it potentially reduces the cost of training a model because instead of having to spend huge amounts of money labeling all this data, if you create the data yourself, you can have it implicitly be labeled.” - Dan --------Show Timestamps:(01:49) How did they get started in tech? (03:14) What brought them to AI?(08:12) What brought them together to write their book?(13:26) Determining which problems can be addressed with AI at the edge(15:51) What possibilities does AI at the edge create for businesses? (20:41) Synthetic data and generative AI (24:15) Using AI for data distillation (31:00) Building a skilled and interdisciplinary team (39:30) AI's transition from a career path to a tool (43:06) Effective AI (46:46) Edge / wildlife conservation case study (49:37) What are they excited about moving forward? --------Sponsor:Over the Edge is brought to you by Dell Technologies to unlock the potential of your infrastructure with edge solutions. From hardware and software to data and operations, across your entire multi-cloud environment, we're here to help you simplify your edge so you can generate more value. Learn more by visiting dell.com/edge for more information or click on the link in the show notes.--------Credits:Over the Edge is hosted by Bill Pfeifer, and was created by Matt Trifiro and Ian Faison. Executive producers are Matt Trifiro, Ian Faison, Jon Libbey and Kyle Rusca. The show producer is Erin Stenhouse. The audio engineer is Brian Thomas. Additional production support from Elisabeth Plutko and Eric Platenyk.--------Links:Follow Bill on LinkedInConnect with Jenny Plunkett on LinkedInConnect with Daniel Situnayake on LinkedIn and TwitterDaniel's substack

The backer kit campaign for Ahoy: New Horizons launches November 14, 2023 here: https://www.backerkit.com/call_to_action/fd610745-96dd-4289-839e-ac0757c468bd/landing00:00 - Intro & genesis of the expansion02:04 - What type of expansion is this04:09 - New factions, same limitations?04:46 - Solo considered?06:09 - Approach to figuring out what to expand08:15 - Smugglers in a 2 player game?10:48 - What makes a good game developer?13:14 - Leder & external designs16:10 - ARCS internal pitch & development20:41 - Role of market research & staying up on games24:13 - Early transparency & impact on creativity29:36 - Minnesota & Board Games32:00 - What makes a Leder game?Links:Our Site - https://www.cardboardherald.comOur Video Channel - https://www.youtube.com/TheCardboardHeraldOur Twitter - https://twitter.com/CardboardHeraldOur Patreon - https://www.patreon.com/user?u=9669551

What is MQTT? Roger Light, Senior Developer at Cedalo and inventor of Mosquitto, joins Ryan Chacon on the IoT For All Podcast to discuss the MQTT protocol in IoT. They talk about the best uses cases for MQTT, alternatives to MQTT, the differences between MQTT brokers, MQTT security, how MQTT fits in the IoT journey, and the future of MQTT. Roger Light is the inventor of open-source Mosquitto (the leading MQTT broker in the world with more than 500 million Docker pulls), and he is the Senior Developer of Pro Mosquitto at Cedalo GmbH. Additionally, Roger is an Assistant Professor, Faculty of Engineering at The University of Nottingham. Since its founding in 2017, Cedalo has been a reliable partner for the global development community. They have stood behind the well-known Mosquitto and Streamsheets open source projects by delivering high-quality and industrial grade versions of them to market with premium support. Currently, they are committed to further developing their Pro Edition for Eclipse Mosquitto and Pro Edition for Streamsheets so that customers can build modern software solutions without breaking their budget. Discover more about MQTT and IoT at https://www.iotforall.com More about Cedalo: https://cedalo.com (00:00) Intro (00:11) Roger Light and Cedalo (00:39) What is MQTT? (01:44) MQTT alternatives (02:36) Best use cases for MQTT (04:06) What differentiates MQTT brokers? (06:12) MQTT security (08:18) Who are the MQTT stakeholders? (09:34) Challenges in MQTT and IoT (11:07) Future of MQTT (13:20) Learn more and follow up SUBSCRIBE TO THE CHANNEL: https://bit.ly/2NlcEwm​ Join Our Newsletter: https://www.iotforall.com/iot-newsletter Follow Us on Social: https://linktr.ee/iot4all Check out the IoT For All Media Network: https://www.iotforall.com/podcast-overview

Join Jon as he interviews Katie Hoesley, Senior Developer Advocate at BigCommerce. In this episode, they delve into the challenges that beginner developers face and explore how to creatively bridge the gap between technical leaders and the next generation of technologists. Drawing from her liberal arts background, Katie emphasizes the importance of creativity, communication, and community in developer advocacy. Don't miss out on their insightful discussion where they unpack the complexities of measuring the ROI of developer marketing the importance of relationships in DevRel, and much more!

Episode 230 of the #MVPbuzzChat interview series. Conversation between Microsoft Regional Director and MVP Christian Buckley (@buckleyplanet), and Business Applications MVP, Keith Atherton (@MrKeithAtherton), a Senior Developer with Quorum Network Resources Ltd, based in Edinburgh, Scotland. You can also find this episode on the CollabTalk blog at https://www.buckleyplanet.com/2023/08/mvpbuzzchat-with-keith-atherton.html

Today on the podcast, we're chatting with Senior Developer Matt Cross about how he got his job, what drives him most in his career and how to get started if you're interested in a development career.

En este episodio tenemos una conversación con destacados profesionales de producto, diseño y desarrollo de la oficina de España. Guy Samuel, Principal Service Line Leader, se une a Azusa Watanabe, Senior Experience Designer; Diana Pinto, Lead Business Analyst; Jeff Zinger, Senior Developer y Luis Mizutani, Lead Business Analyst, para explorar los aspectos más intrincados y sorprendentes del rol de liderazgo en el ámbito de productos.   ¿Qué es lo que hacen los líderes de producto más allá de la definición del rol? A medida que exploramos las características esenciales de un líder de producto excepcional, obtendrás información valiosa sobre las habilidades, enfoques y estrategias que les han permitido destacarse en sus respectivos roles.  

In this episode, Jamie Barton, Senior Developer Relations at Grafbase, joins us to discuss his experiences in the tech industry, developer education, the importance of developer relations, and the impact of GraphQL in the tech ecosystem.

Stephanie is joined by very special guest, fellow thoughtboter, Senior Developer, and marathon trainer Mina Slater. Mina and Stephanie had just been traveling together for two weeks, sponsored by WNB.rb for RubyKaigi in Matsumoto, Japan, and together, they recount their international adventure! RubyKaigi (https://rubykaigi.org/2023/) WNB.rb (https://www.wnb-rb.dev/) Understanding the Ruby Global VM Lock by observing it by Ivo Anjo (https://rubykaigi.org/2023/presentations/KnuX.html#day1) gvl-tracing (https://github.com/ivoanjo/gvl-tracing) Justin Searls' RubyKaigi 2023 live coverage (https://blog.testdouble.com/field-reports/ruby-kaigi/) Prioritizing Learning episode (https://www.bikeshed.fm/362) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn and today. I'm joined by a very special guest, fellow thoughtboter Mina Slater. Mina, would you like to introduce yourself to our audience? MINA: Yeah. Hi, everyone. I am Mina. I am a Senior Developer on Mission Control, which is thoughtbot's DevOps and SRE team. STEPHANIE: So, Mina, what's new in your world? MINA: Well, I start marathon training this week. So I hope that this conversation goes well and lasts you for three months because you're probably not going to see or hear from me all summer. STEPHANIE: Yes. That sounds...it sounds hard, to be honest, marathon training in the summer. When I was doing a bit more running, I always thought I would wake up earlier than I did and, you know, beat the heat, and then I never would, and that really, like, was kind of rough. MINA: Yeah, actually, I was thinking about my plans for today. I didn't wake up early enough to run in the morning. And so I was calculating, like, okay, by midday, it's going to be too hot. So I'm going to have to wait until, like, 6:00 p.m. [laughs] STEPHANIE: Yeah, yeah. Or, if you're like me, there's a very real chance that you just skip it altogether. [laughter] MINA: Well, I have a deadline, so... [laughs] STEPHANIE: That's true. When is your marathon race? MINA: This is actually the first year I'm doing two in a calendar year. So I'm doing Berlin in September. And then, three weeks after that, I'm going to run one in Detroit. STEPHANIE: Nice. At least you'll be ready. You'll, like, have done it. I don't know; it kind of sounds maybe a bit more efficient that way. [laughs] MINA: Theoretically. But, you know, ask me in October. I'll let you know how it goes. STEPHANIE: That's true. You might have to come back on as a guest. [laughs] MINA: Just to talk about how it went. [laughs] STEPHANIE: Yeah, exactly. MINA: So that's what's new with me. What's new in your world, Steph? STEPHANIE: So, a while back on a previous Bike Shed episode, I talked about joining this client team and, in their daily team syncs, in addition to just sharing what we were up to and what we were working on, we would also answer the question what's something new to us. And that was a space for people to share things that they learned or even just, like, new things that they tried, like food, or activities, or whatnot. And I really enjoyed it as a way to get to know the team, especially when I was new to that client project. And recently, someone on the team ended up creating a random question generator. So now the question for the daily sync rotates. And I've been having a lot of fun with that. Some of the ones that I like are, what made you laugh recently? What's currently playing on your Spotify or YouTube? No cheating. MINA: [laughs] STEPHANIE: And then, yesterday, we had what's for dinner? As the question. And I really liked that one because it actually prompted me to [chuckles] think about what I was going to do for dinner as opposed to waiting till 5:00 p.m. and then stressing because I'm already hungry but don't have a plan [chuckles] for how I'm going to feed myself yet. So it ended up being nice because I, you know, kind of was inspired by what other people mentioned about their dinner plans and got my stuff together. MINA: That's shocking to me because we had just come off of two weeks of traveling together. And the one thing I learned about you is that you plan two meals ahead, but maybe that is travel stuff. STEPHANIE: I think that is extremely correct. Because when you're traveling, you're really excited about all the different things that you want to eat wherever you are. And so, yeah, we were definitely...at least I was planning for us, like, two or three meals [laughs] in advance. MINA: [laughs] STEPHANIE: But, when I'm at home, it is much harder to, I don't know, like, be motivated. And it just becomes, like, a daily chore. [laughs] So it's not as exciting. MINA: I think I'm the same way. I just had a whole bunch of family in town. And I was definitely planning dinner before we had breakfast because I'm like, oh, now I have to be responsible for all of these people. STEPHANIE: Yeah. I just mentioned the questions because I've been really having fun with them, and I feel a lot more connected to the team. Like, I just get to know them more as people and the things they're interested in, and what they do in their free time. So, yeah, highly recommend adding a fun question to your daily syncs. MINA: Yeah, we started doing that on Mission Control at our team sync meetings recently, too, where the first person...we actually have an order generator that somebody on the team wrote where it takes everyone's first and last name and scramble them and then randomizes the order. So you kind of have to figure out where in the queue you are and who's coming up next after you. But the first person that goes in the queue every day has to think of an icebreaker question. STEPHANIE: That's kind of a lot of pressure [laughs] for a daily meeting, especially if you're having to unscramble names and then also come up with the icebreaker question. I personally would be very stressed [laughs] by that. But I also can see that it's...I also think it's very fun, especially for a small team like yours. MINA: Yeah, yeah, just seven of us; we get to know really well what letters are in everyone's names. But I was first today, and I didn't have an icebreaker question ready. So I ended up just passing. So that's also an option. STEPHANIE: That's fair. Maybe I'll link you to our random question generator, so you can find some inspiration. [laughs] MINA: Yeah, it's a ChatGPT situation. STEPHANIE: So you mentioned that you and I had just been traveling together for two weeks. And that's because Mina and I were at RubyKaigi in Matsumoto, Japan, earlier this May. And that's the topic of today's episode: Our Experience at RubyKaigi. And the really cool thing that I wanted to mention was that this was all possible because Mina and I were sponsored by WNB.rb, which is a global community of women and non-binary people working in Ruby. And I've mentioned this group on the show before, but I wanted to plug it again because I think that this was something really special that we got to do. WNB runs a lot of initiatives, like, meetups and panels supporting people to speak at conferences and book clubs. And, you know, just many different programming events for supporting women and non-binary Rubyists in their career growth. And they are recently beginning a new initiative to sponsor folks to attend conferences. And Mina, you and I were the first people to get to try this out and go to an international conference. So that was really awesome. It was something that I don't think I would have done without the support from WNB. MINA: And you almost didn't do. I think there was a lot of convincing [chuckles] that went on at the beginning to kind of get you to, like, actually consider coming with me. STEPHANIE: It's true. It's true. I think you had DMed me, and you were, like, so, like, RubyKaigi, like, eyeball emoji. [laughs] I was, I think, hesitant because this was my first international conference. And so there was just a lot of, like, unknowns and uncertainty for me. And I think that's going to be part of what we talk about today. But is there anything that you want to say about WNB and how you felt about being offered this opportunity? MINA: Yeah. When Emily and Jemma, the founders of WNB, approached us with this opportunity and this offer, I think I was...taken aback is not really quite the right words but, like, surprised and honored, really, I think it's a better word. Like, I was very honored that they thought of us and kind of took the initiative to come to us with this offer. So I'm really grateful for this opportunity because going to RubyKaigi, I think it's always something that was on my radar. But I never thought that...well, not never. I thought that I had to go as a speaker, which would have been, like, a three to five-year goal. [laughs] But to be able to go as an attendee with the support of the group and also of thoughtbot was really nice. STEPHANIE: Yeah, absolutely. That investment in our professional development was really meaningful to me. So, like you, I'm very grateful. And if any of our listeners are interested in donating to WNB.rb and contributing to the community's ability to send folks to conferences, you can do so at wnb-rb.dev/donate. Or, if you work for a company that might be interested in sponsoring, you can reach out to them at organizers@wnb-rb.dev. MINA: I highly recommend doing that. STEPHANIE: So, one of the questions I wanted to ask you about in terms of your RubyKaigi experience was, like, how it lined up with your expectations and if it was different or similar to what you were expecting. MINA: Yeah, I have always heard that when people talk about RubyKaigi as a conference and about its contents, the word that everyone uses to describe it is technical. I have already had sort of a little bit of that expectation going in. But I think my interpretation of the word technical didn't really line up with how actually technical it was. And so that was one thing that was different than what I had expected. STEPHANIE: Could you elaborate on what was surprising about the way that it was technical? MINA: Yeah. I think that when I hear technical talks and having been to some Ruby and Rails confs here in the States, when I hear about technical talks, it's a lot more content about people using the technology, how they use Ruby to do certain things, or how they use Rails to achieve certain goals in their day-to-day work or side projects. But it seems at RubyKaigi; it is a lot more about the language itself, how Ruby does certain things, or how interpreters implement Ruby, the language itself. So I think it's much more lower-level than what I was expecting. STEPHANIE: Yeah, I agree. I think you and I have gone to many of Ruby Central conferences in the U.S., like RubyConf and RailsConf. So that was kind of my comparison as well is that was, you know, the experience that I was more familiar with. And then, going into this conference, I was very surprised that the themes of the talks were, like you said, very focused on the language itself, especially performance, tooling, the history and future of Ruby, which I thought was pretty neat. Ruby turns 30, I think, this year. And one thing that I noticed a lot was folks talking about using Ruby to reflect on itself and the possibilities of utilizing those capabilities to improve our experience as developers using the language. MINA: Yeah. I think one of the things I was really fascinated by is...you had mentioned the performance. There were several talks about collecting how Ruby performs at certain levels. And I thought that that was quite interesting and things I had never thought about before, and I'm hoping to think about in the future. [laughs] STEPHANIE: Yeah. One talk that I went to was Understanding the Ruby Global VM Lock by Ivo Anjo. And that was something that, you know, I had an awareness of that Ruby has this GVL and certain...I had, like, a very hand-wavy understanding about how, like, concurrency worked with Ruby because it hasn't been something that I've really needed to know too deeply in my day-to-day work. Like, I feel a little bit grateful not to have run into an issue where I had to, you know, dive deep into it because it was causing problems. [laughs] But attending that talk was really cool because I liked that the speaker did give, like, an overview for folks who might be less familiar but then was able to get really deep in terms of, like, what he was doing workwise with improving his performance by being able to observe how the lock was being used in different threads and, like, where it might be able to be improved. And he shared some of his open-source projects that I'll link in the show notes. But, yeah, that was just something that I was vaguely aware of and haven't yet, like, needed to know a lot about, but, you know, got to understand more by going to this conference. And I don't think I would have gotten that content otherwise. MINA: Yeah, I agree. The talk that you are referencing is one of my favorite as well. I think, like you, kind of this vague idea of there's things going on under the hood in Ruby is always there, but to get a peek behind the curtain a little bit was very enlightening. I wrote down one of the things that he said about how highly optimized Ruby code can still be impacted and be slow if you don't optimize GVL. And he also shared, I think, some strategies for profiling that layer in your product, if that is something you need, which I thought was really cool. STEPHANIE: Yeah. I think I had mentioned performance was a really big theme. But I didn't realize how many levers there were to pull in terms of the way Ruby is implemented or the way that we are able to use Ruby that can improve performance. And it's really cool to see so many people being experts at all of those different components or aspects of making Ruby fast. [laughs] MINA: Yeah. I think that part of the work that we do on Mission Control is monitoring performance and latency for our clients. And while I don't expect having to utilize some of the tools that I learned at RubyKaigi, I expect being aware of these things helping, I think, in the long run. STEPHANIE: Yeah, absolutely. Joël and I have talked on the show about this idea of, like, push versus pull learning. So push, being you consume content that may not be relevant to you right now but maybe will be in the future. And you can remember, like, oh, I watched a talk on this, or I read something about this, and then you can go refer back to it. As opposed to pull being, like, I have this thing that I don't understand, but I need to know right now, so I'm going to seek out resources about it. And I think we kind of landed on that both are important. But at Kaigi, especially, this was very much more push for me where there's a lot of things that I now have an awareness of. But it's a little different, I think, from my experience at Ruby Central conferences where I will look at the schedule, and I will see talks that I'm like, oh, like, that sounds like it will be really relevant to something I'm working through on my client project or, like, some kind of challenging consulting situation. And so the other thing that I noticed that was different was that a lot of the U.S. conferences are more, I think like business and team challenges-focused. So the talks kind of incorporate both a technical and socio-cultural aspect of the problems that they were solving. And I usually really like that because I find them very relatable to my day-to-day work. And that was something that was less common at Kaigi. MINA: Also, that I've never been to a conference that is more on the academic side of things. So I don't know if maybe that is more aligned with what Kaigi feels like. STEPHANIE: Yeah, that's true. I think there were a lot of talks from Ruby Committers who were just sharing, like, what they've been working on, like, what they've been thinking about in terms of future features for Ruby. And it was very much at the end of those talks, like, I'm open to feedback. Like, look out for this coming soon, or, like, help contribute to this effort. And so it was interesting because it was less, like, here are some lessons learned or, like, here are some takeaways, or, like, here's how we did this. And more like, hey, I'm, you know, in the middle of figuring this out, and I'm sharing with you where I'm at right now. But I guess that's kind of the beauty of the open-source community is that you can put out a call for help and contributions. MINA: Yeah, I think they call that peer review in the academic circles. STEPHANIE: [laughs] That's fair. MINA: [laughs] STEPHANIE: Was there anything else that you really enjoyed about the conference? MINA: I think that one of my favorite parts, and we've talked about this a little bit before, is after hours on the second day, we were able to connect with Emori House and have dinner with their members. Emori House is a group that supports female Kaigi attendees specifically. I think it's that they, as a group, rent out an establishment or a house or something, and they all stay together kind of to look out for each other as they attend this very, I think, male-dominated conference. STEPHANIE: Yeah. I loved that dinner with folks from Emori House too. I think the really cool thing to me is that it's just community and action, you know, like, someone wanted to go to this conference and make it easier for other women to go to this conference and decided to get lodging together and do that work of community building. And that social aspect of conferences we hadn't really talked about yet, but it's something that I really enjoy. And it's, like, one of the main reasons that I go to conferences besides learning. MINA: Yeah, I agree. At the Ruby Central conferences, one of my favorite parts is always the hallway track, where you randomly meet other attendees or connect with attendees that you already knew. And like I mentioned, this dinner with Emori House happened on the second night. And I think by midday second day; I was missing that a little bit. The setup for RubyKaigi, I noticed, does not make meeting people and organizing social events as easy as I had been used to, and part of that, I'm sure, is the language barrier. But some places where I had met a lot of the people that I call conference friends for Ruby Central conferences had been at the lunch table. And Kaigi sets up in a way where they send you out with food vouchers for local restaurants, which I thought was really cool. But it doesn't make meeting people and organizing groups to go out together with people you don't already know a little more difficult. So meeting Emori House on the second night was kind of exactly what I had been missing at the moment. STEPHANIE: Yeah, agreed. I also really thrive off of more smaller group interactions like organically, you know, bumping into people on the hallway track, ideally. I also noticed that, at Kaigi, a lot of the sponsors end up hosting parties and meetups after the conference in the evenings. And so that was a very interesting social difference, I think, where the sponsors had a lot more engagement in that sense. You and I didn't end up going to any of those drink-ups, are what they're called. But I think, similarly, if I were alone, I would be a little intimidated to go by myself. And it's kind of one of those things where it's like, oh, if I know someone, then we can go together. But, yeah, I certainly was also missing a bit of a more organic interaction with others. Though, I did meet a few Rubyists from just other places in East Asia, like Taiwan and China. And it was really cool to be in a place where people are thinking about Ruby differently than in the U.S. I noticed in Japan; there's a lot more energy and enthusiasm about it. And, yeah, just folks who are really passionate about making Ruby a long-lasting language, something that, you know, people will continue to want to work with. And I thought that was very uplifting because it's kind of different from what the current industry in the U.S. is looking like in terms of programming languages for the jobs available. MINA: It's really energizing, I think, to hear people be so enthusiastic about Ruby, especially, like you said, when people ask me what I do here, I say, "Developer," and they say, "Oh, what language do you work in?" I always have to be kind of like, "Have you heard of Ruby?" [laughs] And I think it helps that Ruby originated in Japan. They probably feel a little bit, like, not necessarily protective of it, but, like, this is our own, and we have to embrace it and make sure that it is future-facing, and going places, and it doesn't get stale. STEPHANIE: Right. And I think that's really cool, especially to, you know, be around and, like, have conversations about, like you said, it's very energizing. MINA: Yeah, like you mentioned, we did meet several other Rubyists from, like, East Asian countries, which doesn't necessarily always happen when you attend U.S.-based or even European-based conferences. I think that it is just not as...they have to travel from way farther away. So I think it's really cool to hear about RubyConf Taiwan coming up from one of the Rubyists from Taiwan, which is awesome. And it makes me kind of want to go. [laughs] STEPHANIE: Yeah, I didn't know that that existed either. And just realizing that there are Rubyists all over the world who want to share the love of the language is really cool. And I am definitely going to keep a lookout for other opportunities. Now that I've checked off my first international conference, you know, I have a lot more confidence about [laughs] doing it again in the future, which actually kind of leads me to my next question is, do you have any advice for someone who wants to go to Kaigi or wants to go to an international conference? MINA: Yeah, I think I have both. For international conferences in general, I thought that getting a buddy to go with you is really nice. Steph and I were able to...like, you and I were able to kind of support each other in different ways because I think we're both stressed [laughs] about international travel in different ways. So where you are stressed, I'm able to support, and where I'm stressed, you're able to support. So it was really nice and well-rounded experience because of that. And for RubyKaigi specifically, I would recommend checking out some of the previous year's talks before you actually get there and take a look at the schedule when it comes out. Because, like we said, the idea of, I think, technical when people use that word to describe the content at RubyKaigi is different than what most people would expect. And kind of having an idea of what you're getting into by looking at previous videos, I think, will be really helpful and get you in the right mindset to absorb some of the information and knowledge. STEPHANIE: Yeah, absolutely. I was just thinking about...I saw in Ruby Weekly this week Justin Searls had posted a very thorough live blogging of his experience at Kaigi that was much more in the weeds of, like, all of the content of the talks. And also had tips for how to brew coffee at a convenience store in Japan too. So I recommend checking that out if folks are curious about...especially this year before the videos of the talks are out. I think one thing that I would do differently next time if I were to attend Kaigi or attend a conference that supports multiple languages...so there were talks in Japanese and English, and the ones in Japanese were live interpreted. And you and I had attended, like, one or two, but it ended up being a little tough to follow because the slides were a little bit out of sync with the interpretation. I definitely would want to try again and invest a little more into attending talks in Japanese because I do think the content is still even different from what we might be seeing in English. And now that I know that it takes a lot of mental energy, just kind of perhaps loading up on those talks in the morning while I'm still, you know -- MINA: [laughs] STEPHANIE: Fresh-faced and coffee-driven. [laughs] Rather than saving it for the afternoon when it might be a little harder to really focus. MINA: I think my mental energy has a very specific sweet spot because definitely, like, late in the afternoon would not be good for that. But also, like, very early in the morning would also not be very good for that because my coffee hasn't kicked in yet. STEPHANIE: That's very real as well. MINA: Do you think that there is anything that the conference could have done to have made your experience a little tiny bit better? Is there any support that you could have gotten from someone else, be it the conference, or WNB, or thoughtbot, or other people that you had gone with that could have enhanced this experience? STEPHANIE: Hmm, that's an interesting question. I'm not really sure because I was experiencing so many new things -- MINA: [laughs] STEPHANIE: That that was kind of, like, what was top of mind for me was just getting around even just, like, looking at all the little sponsor booths because that was, like, novel for me to see, like, different companies that I've never heard of before that I think when I asked you about expectations earlier, like, I actually came in with not a lot of expectations because I really was just open to whatever it was going to be. And now that I've experienced it once, I think that I have a little more of an idea of what works for me, what I like, what I don't like. And so I think it really comes down to it being quite a personal experience and how you like to attend conferences and so -- MINA: For sure. STEPHANIE: At the end of the day, yeah, like, definitely recommend just going if that opportunity is available to you and determining for yourself how you want that experience to be. MINA: Certainly. I think just by being there you learn a lot about what you like in conferences and how we like to attend conferences. On a personal level, I'm also an organizer with Ruby Central with their scholarship committee. And that's somewhere where we take new Rubyists or first-time conference attendees and kind of lower the barrier for them to attend these conferences. And the important part I wanted to get to is setting them up with a mentor, somebody who has attended one of these conferences before that can kind of help them set goals and navigate. And I thought that someone like that would...at RubyKaigi, being both our first times, might be useful. STEPHANIE: Yeah, absolutely. I think that's totally fair. One thing I do really like about the Ruby Central conferences is the social support. And I think you had mentioned that maybe that was the piece that was a little bit missing for you at this conference. MINA: Yeah. I know that someone had asked early on, I think, like, the night before the conference officially kicked off, whether there is a Slack or Discord space for all conference attendees so that people can organize outings or meals. And that is definitely something that at least the Ruby Central conferences have, and I imagine other conferences do too, that was missing at Kaigi as well. STEPHANIE: I'm wondering if you would go to Kaigi again and maybe be that mentor for someone else. MINA: I think so. I think I had different feelings about it when we were just leaving the conference, kind of feeling like some of these things that I'm learning here or that I'm being made aware of rather at RubyKaigi will come up important in the future, but maybe not right away. So then I was kind of walking away with a sense of, like, oh, maybe this is a conference that is important, but I might deprioritize if other opportunities come up. But then I started to kind of, like, jot down some reflections and retroing with myself on this experience. And I thought what you mentioned about this being the sort of, like, the push learning opportunity is really nice because I went in there not knowing what I don't know. And I think I came out of it at least being a little bit aware of lots of things that I don't know. STEPHANIE: Yeah, yeah. Maybe, like, what I've come away with this conversation is that there is value in conferences being different from each other, like having more options. And, you know, one conference can't really be everything for everyone. And so, for you and I to have had such a very different experience at this particular conference than we normally do, that has value. It also can be something that you end up deciding, like, you're not into, and then you know. So, yeah, I guess that is kind of what I wanted to say about this very new experience. MINA: Yeah, having new experiences, I think, is the important part. It's the same idea as you want to get a diverse group of people in the room together, and you come out with better ideas or better products or whatever because you have other points of view. And I think that attending conferences, even if not around the world, that are different from each other either in academia or just kind of, like, branching out of Ruby Central conferences, too, is a really valuable experience. Maybe conferences in other languages or language-agnostic conferences. STEPHANIE: Yeah, well said. On that note, shall we wrap up? MINA: Let's do it. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeee!!!!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

EPISODE DESCRIPTION:You have ideas for an app or two but aren't quite sure where to start. Or maybe you've started but keep hitting some road blocks. In this Dev Life edition of the Angular Plus Show, Brooke & guest host Jordan Powell talk with our first three-peat guest, Colum Ferry, Senior Developer from NxDevTools, all about his new application and side project - GrammarGuru. Colum shares his experiences taking the app from concept to deployment, with all the details between, from choosing your techstack, working with business partners, overcoming barriers, and more! You'll be fully armed and ready to make your app ideas a reality too! This is… The Dev Life!LINKS:https://twitter.com/FerryColumhttps://grammarguru.appThe Blackstone Legacy by Colum FerryCONNECT WITH US:Colum Ferry - @FerryColumBrooke Avery - @jediBraveryJordan Powell - @JordanPowell88

In this episode, PJ Hagerty, Senior Developer Advocate at Spotify, joins us to talk about why Spotify is such an interesting place to work, the parallels between coding and music and why the education system needs to change the way it teaches math and coding.

Today's guest is Chuck Tomasi, Senior Developer Advocate at ServiceNow. Based in Phoenix, Arizona, Chuck has over 40 years of experience in the IT industry which has given him the skills to leverage industry best practices, create lean processes, and provide his customers with the best service and solutions possible. His experience includes global team management, program rollout and leading small to medium (

Simple Programmer is now BACK with a brand new YouTube Channel- SUBSCRIBE HERE: https://simpleprogrammer.com/subscribespyt

Tegan Ashby is the Assistant Director of Software Engineering for the Philadelphia Phillies. Before that, she worked in the NBA as a Senior Developer of Basketball Systems for the Brooklyn Nets, and as a Developer of Research & Development for the Philadelphia 76ers.. She holds a BA in Linguistics from Penn, and took classes at Cal Berkeley's Ancient Neat Eastern and Biblical Languages, Literatures, and Linguistics Graduate Studies program. In this conversation, Tegan talks about…What a software engineer does and how it applies to a baseball team.What kinds and volumes of data MLB teams deal with.The difference between a development job with an NBA team compared to an MLB team.What NBA engineering looks like.Her background in Linguistics and how it helps her in her profession.Advice on sports-specific tools for someone learning software engineering.Co-founding the Women In Sports Data and how people can support the initiative.Then, TruMedia's Sergio De La Espriella joins the show to discuss Paul's conversation with Tegan.Show LinksFollow Tegan on Twitter: @bunsushiFollow Women in Sports Data on Twitter: @WinSportsDataFor more on Women in Sports Data, click here.For more on SportsDataVerse, click here.To check out Tegan's website, click here.To check out Tegan on LinkedIn, click here.Follow @TruMediaSports on Twitter.Listen here or wherever you get your podcasts: Apple, Spotify, Google, Stitcher, TuneIn.

A senior developer understands that they have to be very selective about how they apply knowledge. Know matter how vast your knowledge may be, you are limited in how you can practically use it in a given circumstance.

On this episode of Remote Ruby, Chris came down with what he thinks was food poisoning this week, Jason brings up Ghost Kitchens which seem to be a thing these days, and Chris applied to be a Guide at RailsConf 2023. Also, Jason and Chris are excited to have a guest joining them because they've always talked about how they wished for better tooling for day-to-day Ruby development, so they brought on Vini Stock, who's a Senior Developer at Shopify. Shopify has created the Ruby Language Server (LSP) to make it easier to implement features such as code definition and auto formatting for Ruby across different editors. We're so lucky to have Vini with us to discuss the Ruby LSP and some other really cool things happening in the Ruby tooling space. We hope you enjoy this episode! Hit the download button now.[00:06:19] Vini shares his journey of programming and working with the Ruby on Rails Infrastructure team.[00:08:27] Now that Vini is on the Ruby Infrastructure team, we find out what kind of projects he was first working on. [00:12:04] How long has the Ruby Experience team and the LSP project been a thing?[00:12:44] Vini explains why the Ruby LSP was created. [00:15:25] Let's find out some goals they want to achieve with the LSP right now.[00:17:37] We hear some of the differences between the work Vini's doing on Ruby LSP and something like Solargraph.[00:19:01] Listen here as Vini details how Go To Definition works, which is a more complex feature than others.[00:24:34] Jason asks Vini what language do you write a language server in? [00:27:26] Chris wonders what challenges Vini runs into and what's the next step of the problem of building the language server. Where does he go from there? [00:31:38] Vini shares his aha moment when he built a feature and used it, and he was thinking, “Build with joy!” [00:32:46] We hear if Vini's using RuboCop or Syntax tree for formatting, which leads him into telling us about future plans of adding a plugin system to be able to format with standard and with Ruby format. [00:35:56] Vini shares other ideas he has for the future of the Ruby LSP.[00:37:11] Outside of the LSP, we hear about some other projects Shopify is working on with contributing to the new Ruby debugger, Chris expresses his appreciation for all the new tooling the team at Shopify is working on, and Jason expresses his love for the Rust tooling.[00:42:18] Have you seen Gary Bernhardt's talk on building an editor? [00:46:27] If you want to try Ruby LSP, Vini tells us where to go to set up VS Code.[00:50:29] There's a great blog post Vini wrote, a video with his talk from RailsConf 2022, and find out where you can follow him online.Panelists:Jason CharnesChris OliverGuest:Vinicius (Vini) StockSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterVinicius Stock TwitterVinicius Stock GitHubVinicius Stock WebsiteRuby LSP (VS Code extension)Ruby LSP-ShopifyImproving the Developer Experience with the Ruby LSP by Vinicius StockRubyConf 2022- Improving the development experience with language servers by Vinicius Stock (YouTube)RailConf 2023A Whole New World-A talk by Gary Bernhardt from Strange Loop 2012Ruby Radar TwitterRuby for All Podcast

In this Dev Life edition of the Angular Plus Show, we talk with Stephen Cooper, a Senior Developer from AG Grid, about some of his proudest achievements as a programmer, the top skills he feels that have helped him reach that success, and possibly some discussion about peanut butter cups. Brooke & Preston then reflect on how EVERY developer can have these kinds of professional wins and proud achievements in their careers as well.LINKS:https://twitter.com/SCooperDevhttps://dev.to/scooperdevhttps://www.ag-grid.com/CONNECT WITH US:Stephen Cooper - @SCooperDevBrooke Avery - @jediBraveryPreston Lamb - @PrestonJLamb

The traits that define a senior engineer are not catalogued perfectly in one spot. But, nevertheless, we'll try to cover some of the most important traits and habits of a senior engineer.In today's episode, we'll add more detail to the commonly recommended skill of "work breakdown." Sometimes this extremely valuable skill is the opposite of what you really need to practice.Feel free to incorporate these into your skill matrices, reviews, or job descriptions - I'd love to hear about it if you do!

The traits that define a senior engineer are not catalogued perfectly in one spot. But, nevertheless, we'll try to cover some of the most important traits and habits of a senior engineer. In this episode, we'll discuss the fact that difficulty does not equate to value, and hazard a guess as to why we can easily confuse this, especially as we begin to grow from junior to senior roles. Feel free to incorporate these into your skill matrices, reviews, or job descriptions - I'd love to hear about it if you do!

The traits that define a senior engineer are not catalogued perfectly in one spot. But, nevertheless, we'll try to cover some of the most important traits and habits of a senior engineer.In this episode, we'll discuss the importance of systematically communicating value to various audiences.Feel free to incorporate these into your skill matrices, reviews, or job descriptions - I'd love to hear about it if you do!

What to do with a slow senior developer?

The traits that define a senior engineer are not catalogued perfectly in one spot. But, nevertheless, we'll try to cover some of the most important traits and habits of a senior engineer.Feel free to incorporate these into your skill matrices, reviews, or job descriptions - I'd love to hear about it if you do!

In this potluck episode of Syntax, Wes and Scott answer your questions about how to give feedback on the podcast, deciding on a business model for courses, what to do about Twitter, and more. Linode - Sponsor Whether you're working on a personal project or managing enterprise infrastructure, you deserve simple, affordable, and accessible cloud computing solutions that allow you to take your project to the next level. Simplify your cloud infrastructure with Linode's Linux virtual machines and develop, deploy, and scale your modern applications faster and easier. Get started on Linode today with a $100 in free credit for listeners of Syntax. You can find all the details at linode.com/syntax. Linode has 11 global data centers and provides 24/7/365 human support with no tiers or hand-offs regardless of your plan size. In addition to shared and dedicated compute instances, you can use your $100 in credit on S3-compatible object storage, Managed Kubernetes, and more. Visit linode.com/syntax and click on the “Create Free Account” button to get started. Sentry - Sponsor If you want to know what's happening with your code, track errors and monitor performance with Sentry. Sentry's Application Monitoring platform helps developers see performance issues, fix errors faster, and optimize their code health. Cut your time on error resolution from hours to minutes. It works with any language and integrates with dozens of other services. Syntax listeners new to Sentry can get two months for free by visiting Sentry.io and using the coupon code TASTYTREAT during sign up. Freshbooks - Sponsor Get a 30 day free trial of Freshbooks at freshbooks.com/syntax Show Notes 00:10 Welcome 01:51 Podcast feedback 04:46 Can you talk about how you made the decision to re-write LevelUp? Strangler Fig 13:54 How did you get a score for your website? Google Pagespeed 19:30 Where will we move to when Twitter implodes? Twitter Blue 26:29 Sponsor: Linode 27:06 How did you arrive at your business model? 33:15 Advice for getting into freelancing web dev? 38:49 Sponsor: Sentry 40:07 How to feel more “senior” as a developer 43:30 How do you manage notifications between various apps? Hazel 50:46 Label makers Nimbot label makers 54:14 Sponsor: Freshbooks 54:45 How are people testing node apps? JestJS Vitest Mocha ChaiJS 56:38 What are your thoughts on the TanStack Router? Tanstack Astro SvelteKit Nozzle 01:09 SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× Scott: Sensibo Air Wes: We Crashed Shameless Plugs Scott: LevelUp Tutorials Wes: Wes Bos Tutorials Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Benedicte pitches her latest side project to a database startup. Benedikt gets an interesting question from his mentee. Read Benedikt and Jesse's back and forth about shipping updates Prune Your Follows Campfire Labs – a content company Traction – a book by Gabriel Weinberg and Justin Mares First Ruby Friend Senior Engineer Mindset – a book by Swizec Teller Benedikt and the Userlist team are putting the finishing touches on their message composer, which will be deployed to projection very soon. He also met with his First Ruby Friend mentee this week and got an interesting question: how do you become a senior developer?Benedicte just pitched her latest side project, Prune Your Follows, to a database startup and will be having a meeting with them later this week. This new opportunity has gotten her excited about the prospect of turning future side projects as viable lines of business.

Five years ago, Carolina got rejected from Shopify after graduating from university in Colombia. She never thought she would end up working in that company as a Senior Developer pursuing one of her passions with Blockchain. In this talk, Carolina will share her journey from the past years, hoping that her failures and learnings will help someone else's journey.

Scott Simons is a successful car dealer that is involved in multiple businesses across many industries. Scott's main focus is in the auto industry. He is the Managing Partner and General Manager of five Carter Myers Automotive dealerships in West Virginia. He is a speaker, business consultant, astute investor, and purveyor of filling the cups of anyone who is willing to put in the effort.Scott shares specific tactical advice you can apply and how he continues to push himself by surrounding himself with those he can learn from .What we discuss in this episode:If you own or manage a dealership, you must be willing to explore new growth opportunities and embrace new ideas. Dealerships that embrace the future will maintain their profitability and relevance in the coming years. Those who do not will be squeezed out of a tightening landscape. In this week's episode of the Dealer Playbook, Scott Simons goes into great detail about Creating A Dealership Growth Environment. As a true leader and an excellent communicator, he ensures that each member of his team understands their role and works together to further the company's growth.While Building a Great Team. Investing in employee training, retention, and happiness is critical to growth and success for your dealership. A motivated, positive team is your greatest asset in building competitive advantage for your business over the long term.Customer service is easily the auto industry's best salesperson. With customer emotions running so hot,it's crucial for your auto dealership to give every facet of customer service the finest polish imaginable. Due to the "virtuous circle" nature of the automotive industry, where strong customer service performance brings customers back later to the showroom floor—and the other way around—there is no doubt that this will pay off in amazing ways.How doing business with your own people make your climb to success is betterScott stocks his view on training employees “training is not it's not a knowing issue here, people know what to do. It's a motivation issue. And I need to help motivate them and get the best out of them. That's my job is to give them all the tools in order to be successful and give them an environment to thrive.”Chain of Command in Organizational Structure establishes accountability, it lays out a company's lines of authority and decision-making power. A proper chain of command ensures that every task, job position and department has one person assuming responsibility for performance.To unify competing desires and perspectives, emphasize that choices be made in the best interest of the customer.How Scott pours back into his team weekly including monitoring their personal credit, managing expenses, and much more that's lead to saving their livesGrowth and rewards have always been critical components of human resources and employee motivation. Furthermore, most people want to advance in their careers. To keep employees longer in your organization, you should provide them with a Personal Development Plan. You can use this plan to map out employee development. How does a Junior Developer advance to the level of Senior Developer? Or, how can a Manager improve in his or her position? Another advantage of employee development is that by promoting employees internally, you can easily fill senior positions within your organization. Furthermore, because you already know everything there is to know about the employee, you are less likely to hire the wrong person for the job.To keep your employees and increase growth in your dealership, one of the most important factors is company culture. Before using motivation-boosting methods such as rewards and development, preparing your organization to support these changes is important. It's not about having the right infrastructure, but also having the right people in the right place. You must create an en

Scott Simons is a successful car dealer that is involved in multiple businesses across many industries. Scott's main focus is in the auto industry. He is the Managing Partner and General Manager of five Carter Myers Automotive dealerships in West Virginia. He is a speaker, business consultant, astute investor, and purveyor of filling the cups of anyone who is willing to put in the effort. Scott shares specific tactical advice you can apply and how he continues to push himself by surrounding himself with those he can learn from . What we discuss in this episode: If you own or manage a dealership, you must be willing to explore new growth opportunities and embrace new ideas. Dealerships that embrace the future will maintain their profitability and relevance in the coming years. Those who do not will be squeezed out of a tightening landscape. In this week's episode of the Dealer Playbook, Scott Simons goes into great detail about Creating A Dealership Growth Environment. As a true leader and an excellent communicator, he ensures that each member of his team understands their role and works together to further the company's growth. While Building a Great Team. Investing in employee training, retention, and happiness is critical to growth and success for your dealership. A motivated, positive team is your greatest asset in building competitive advantage for your business over the long term. Customer service is easily the auto industry's best salesperson. With customer emotions running so hot,it's crucial for your auto dealership to give every facet of customer service the finest polish imaginable. Due to the "virtuous circle" nature of the automotive industry, where strong customer service performance brings customers back later to the showroom floor—and the other way around—there is no doubt that this will pay off in amazing ways. How doing business with your own people make your climb to success is better Scott stocks his view on training employees “training is not it's not a knowing issue here, people know what to do. It's a motivation issue. And I need to help motivate them and get the best out of them. That's my job is to give them all the tools in order to be successful and give them an environment to thrive.” Chain of Command in Organizational Structure establishes accountability, it lays out a company's lines of authority and decision-making power. A proper chain of command ensures that every task, job position and department has one person assuming responsibility for performance. To unify competing desires and perspectives, emphasize that choices be made in the best interest of the customer. How Scott pours back into his team weekly including monitoring their personal credit, managing expenses, and much more that's lead to saving their lives Growth and rewards have always been critical components of human resources and employee motivation. Furthermore, most people want to advance in their careers. To keep employees longer in your organization, you should provide them with a Personal Development Plan. You can use this plan to map out employee development. How does a Junior Developer advance to the level of Senior Developer? Or, how can a Manager improve in his or her position? Another advantage of employee development is that by promoting employees internally, you can easily fill senior positions within your organization. Furthermore, because you already know everything there is to know about the employee, you are less likely to hire the wrong person for the job. To keep your employees and increase growth in your dealership, one of the most important factors is company culture. Before using motivation-boosting methods such as rewards and development, preparing your organization to support these changes is important. It's not about having the right infrastructure, but also having the right people in the right place. You must create an environment that naturally stimulates motivation. Listen to the full episode for insights and context from Scott Simons Like this show? Please leave us a review here — even one sentence helps! Consider including your LinkedIn or Instagram handle so we can thank you personally! Thanks, Scott Simons! If you enjoyed this episode featuring Scott Simons, support us by clicking the links! Connect with Scott Simons on LinkedIn Connect with Michael Cirillo Connect with Michael on LinkedIn

Hello, and welcome to another episode of CISO Tradecraft, the podcast that provides you with the information, knowledge, and wisdom to be a more effective cybersecurity leader.  My name is G. Mark Hardy, and today we're going to try to balance the impossible equation of better, faster, and cheaper.  As always, please follow us on LinkedIn, and subscribe if you have not already done so. Shigeo Shingo, who lived from 1909-1990, helped to improve efficiency at Toyota by teaching thousands of engineers the Toyota Production System, and even influenced the creation of Kaizen.  He wrote, "There are four purposes for improvement: easier, better, faster, cheaper. These four goals appear in order of priority." Satya Nadella, the CEO of Microsoft, stated that, “Every company is a software company.  You have to start thinking and operating like a digital company.  It's no longer just about procuring one solution and deploying one solution… It's really you yourself thinking of your own future as a digital company, building out what we refer to as systems of intelligence.” The first time I heard this I didn't really fully understand it.  But after reflection it makes a ton of sense.  For example, let's say your company couldn't send email.  How much would that hurt the business?  What if your company couldn't use Salesforce to look up customer information?  How might that impact future sales?  What if your core financial systems had database integrity issues?  Any of these examples would greatly impact most businesses.  So, getting high-quality software applications that enable the business is a huge win. If every company is a software or digital company, then the CISO has a rare opportunity.  That is, we can create one of the largest competitive advantages for our businesses. What if we could create an organization that builds software cheaper, faster, and better than all of our competitors? Sounds good right?  That is the focus of today's show, and we are going to teach you how to excel in creating a world class organization through a focused program in Secure Software Development.  Now if you like the sound of better, faster, cheaper, as most executives do, you might be thinking, where can I buy that?  Let's start at the back and work our way forward. We can make our software development costs cheaper by increasing productivity from developers. We can make our software development practices faster by increasing convenience and reducing waste. We can make our software better by increasing security. Let's first look at increasing productivity.  To increase productivity, we need to under    stand the Resistance Pyramid.  If you know how to change people and the culture within an organization, then you can significantly increase your productivity.  However, people and culture are difficult to change, and different people require different management approaches. At the bottom of the pyramid are people who are unknowing.  These individuals Don't know what to do.  You can think of the interns in your company.  They just got to your company, but don't understand what practices and processes to follow.  If you want to change the interns, then you need to communicate what is best practice and what is expected from their performance.  Utilize an inquiry approach to decrease fear of not knowing, for example, "do you know to whom I should speak about such-and-such?" or "do you know how we do such-and-such here?"  An answer of "no" allows you to inform them of the missing knowledge in a conversational rather than a directional manner. The middle part of the pyramid is people who believe they are unable to adapt to change.  These are individuals that don't know how to do the task at hand.  Here, communications are important, but also skills training.  Compare your team members here to an unskilled labor force -- they're willing to work but need an education to move forward.  If you give them that, then the unskilled can become skilled. However, if you never invest in them, then you will not increase your company's productivity and lowers your costs. At the Top of the resistance pyramid are the people who are unwilling.  These individuals Don't Want to Change.  We might call these folks the curmudgeons that say we tried it before, and it doesn't work.  Or I'm too old to learn that.  If you want to change these individuals and the culture of an organization, then you need to create motivation. As leaders, our focus to stimulate change will be to focus on communicating, educating, and motivating.  The first thing that we need to communicate is the Why.  Why is Secure Software Development important?  The answer is money.  There are a variety of studies that have found that when software vulnerabilities get detected in the early development processes, they are cheaper than later in the production phases.  Research from the Ponemon Institute in 2017 found that the average cost to address a defect in the development phase was $80, in the build phase was $240, in the QA/Test Phase was $960, and in the Production phase was $7,600.  Think of that difference.  $80 is about 1% of $7,600.  So if a developer finds bugs in the development code then they don't just save their time, they save the time of second developer who doesn't have to do a failed code review, they save the time of an infrastructure engineer who has to put the failed code on a server, they save the time of another tester who has to create regression tests which fail, they save the time of a wasted change approval board on a failed release, and they save the customer representatives time who will respond to customers when the software is detected as having issues.  As you see there's a lot of time to be saved by increasing productivity, as well as a 99% cost savings for what has to be done anyway.  Saving their own time is something that will directly appeal to every development team member. To do this we need to do something called Shift Left Testing.  The term shift left refers to finding vulnerabilities earlier in development.  To properly shift left we need to create two secure software development programs. The first program needs to focus on is the processes that an organization needs to follow to build software the right way.  This is something you have to build in house.  For example, think about how you want software to create a network diagram that architects can look at in your organization.  Think about the proper way to register an application into a Configuration Management Database so that there is a POC who can answer questions when an application is down.  Think about how a developer needs to get a DNS entry created for new websites.  Think about how someone needs to get a website into the various security scanning tools that your organization requires (SAST, DAST, Vuln Management, Container Scanning, etc.)  Think about how developers should retire servers at the end of life.  These practices are unique to your company.  They may require a help desk ticket to make something happen or if you don't have a ticketing system, an email.  We need to document all of these into one place where they can be communicated to the staff members who will be following the processes.  Then our employee has a checklist of activities they can follow.  Remember if it's not in the checklist, then it won't get done.  If it doesn't get done, then bad security outcomes are more likely happen.  So, work with your architects and security gurus to document all of the required practices for Secure Software Development in your company.  You can place this knowledge into a Wikipedia article, a SharePoint site, a Confluence Page, or some kind of website.  Make sure to communicate this frequently.  For example, have the CIO or CISO share it at the IT All Hands meeting.  Send it out in monthly newsletters.  Refer to it in security discussions and architecture review boards.  The more it's communicated the more unknowing employees will hear about it and change their behavior. The second program that you should consider building is a secure code training platform.  You can think of things such as Secure Code Warrior, HackEDU (now known as Security Journey), or Checkmarx Code Bashing.  These secure code training solutions are usually bought by organizations instead of being created in-house.  They teach developers how to write more secure code.  For example, "How do I write JavaScript code that validates user input, sanitizes database queries, and avoids risky program calls that could create vulnerabilities in an application?"  If developers gain an education in secure programming, then they are less likely to introduce vulnerabilities into their code.  Make these types of training programs available to every developer in your company. Lastly, we need to find a way to motivate the curmudgeons.  One way to do that is the following:Let's say you pick one secure coding platform and create an initial launch.  The first two hundred people in the organization that pass the secure developer training get a one-time bonus of $200.  This perk might get a lot of people interested in the platform.  You might even get 10-20% of your organization taking the training in the first quarter of the program.  The second quarter your organization announces that during performance reviews anyone who passed the secure software training will be viewed more favorable than their peers.  Guess what?  You will see more and more people taking the training class.  Perhaps you see that 50% of your developer population becomes certified.  Then the following year you say since so many developers are now certified, to achieve the rank of Senior Developer within the organization, it is now expected to pass this training.  It becomes something HR folks look for during promotion panels.  This gradual approach to move the ball in training can work and has been proven to increase the secure developer knowledgebase. Here's a pro tip:  Be sure to create some kind of badges or digital certificates that employees can share.  You might even hand out stickers upon completion that developers can proudly place on their laptops.  Simple things like this can increase visibility.  They can also motivate people you didn't think would change. Now that we have increased productivity from the two development programs (building software the right way and a secure code training platform), it's time to increase convenience and reduce waste.  Do you know what developers hate?  Well, other than last-minute change requests.  They hate inefficiencies.  Imagine if you get a vulnerability that says you have a bug on line 242 in your code.  So you go to the code, and find there really isn't a bug, it's just a false positive in the tool.  This false bug detection really, well, bugs developers.  So, when your organization picks a new SAST, DAST, or IAST tool, be sure to test the true and false positive rates of the tool.  One way to do this is to run the tools you are considering against the OWASP Benchmark.  (We have a link to the OWASP Benchmark in our show notes.)  The OWASP Benchmark allows companies to test tools against a deliberately vulnerable website with vulnerable code.  In reality, testing tools find both good code and bad code.  These results should be compared against the ground truth data to determine how many true/false positives were found.  For example, if the tool you choose has a 90% True Positive Rate and a 90% False Positive Rate then that means the tool pretty much reports everything is vulnerable.  This means valuable developer time is wasted and they will hate the tool despite its value.  If the tool has a 50% True Positive Rate and a 50% False positive rate, then the tool is essentially reporting randomly.  Once again, this results in lost developer confidence in the tool.  You really want tools that have high True Positive Rates and low False Positive Rates.  Optimize accordingly. Another developer inefficiency is the amount of tools developers need to leverage.  If a developer has to log into multiple tools such as Checkmarx for SAST findings, Qualys for Vulnerability Management findings, Web Inspect for DAST findings, Prisma for Container Findings, Truffle Hog for Secrets scanning, it becomes a burden.  If ten systems require two minutes of logging in and setup each that's twenty minutes of unproductive time.  Multiply that time the number of developers in your organization and you can see just how much time is lost by your team just to get setup to perform security checks.  Let's provide convenience and make development faster.  We can do that by centralizing the security scanning results into one tool.  We recommend putting all the security findings into a Source Code Repository such as GitHub  or GitLab.  This allows a developer to log into GitHub every day and see code scanning vulnerabilities, dependency vulnerabilities, and secret findings in one place.  This means that they are more likely to make those fixes since they actually see them.  You can provide this type of view to developers by buying tools such as GitHub Advanced Security.  Now this won't provide all of your security tools in one place by itself.  You still might need to show container or cloud findings which are not in GitHub Advanced Security.  But this is where you can leverage your Source Code Repository's native CI/CD tooling.  GitHub has Actions and GitLab has Runners.  With this CI/CD function developers don't need to go to Jenkins and other security tools.  They can use a GitHub Actions to integrate Container and Cloud findings from a tool like Prisma.  This means that developers have even fewer tools from CI/CD perspectives as well less logging into security tools.  Therefore, convenience improves.  Now look at it from a longer perspective.  If we get all of our developers integrating with these tools in one place, then we can look in our GitHub repositories to determine what vulnerabilities a new software release will introduce.  This could be reviewed at Change Approval Board.  You could also fast track developer who are coding securely.  If a developer has zero findings observed in GitHub, then that code can be auto approved for the Change Approval.  However, if you have high/critical findings then you need manager approvals first.  These approvals can be codified using GitHub code scanning, which has subsumed the tool Looks Good To Me (LGTM), which stopped accepting new user sign-ups last week (31 August 2022).  This process can be streamlined into DevSecOps pipelines that improve speed and convenience when folks can skip change approval meetings. Another key way we can make software faster is by performing value stream mapping exercises.  Here's an example of how that reduces waste.  Let's say from the time Nessus finds a vulnerability there's actually fifteen steps that need to occur within an organization to fix the vulnerability.  For example, the vulnerability needs to be assigned to the right team, the team needs to look at the vulnerability to confirm it's a legitimate finding, a patch needs to be available, a patch needs to be tested, a change window needs to be available, etc.  Each of these fifteen steps take time and often require different handoffs between teams.  These activities often mean that things sit in queues.  This can result in waste and inefficiencies.  Have your team meet with the various stakeholders and identify two time durations.  One is the best-case time for how long something should go through in an optimal process.  The second is the average time it takes things to go through in the current process.  At the end of it you might see that the optimal case is that it takes twenty days to complete the fifteen activities whereas the average case takes ninety days.  This insight can show you where you are inefficient.  You can identify ways to speed up from ninety to twenty days.  If you can do this faster, then developer time is gained.  Now, developers don't have to wait for things to happen.  Making it convenient and less wasteful through value stream mapping exercises allows your teams to deploy faster, patch faster, and perform faster. OK last but not least is making software better by increasing security.   At the end of the day, there are many software activities that we do which provide zero value to the business.  For example, patching operating systems on servers does not increase sales.  What makes the sales team sell more products?  The answer is more features on a website such as product recommendations, more analysis of the data to better target consumers, and more recommendations from the reporting to identify better widgets to sell.  Now, I know you are thinking, did CISO Tradecraft just say to not patch your operating systems?  No, we did not.  We are saying patching operating systems is not a value-add exercise.  Here's what we do recommend.  Ask every development team to identify what ike patching.  Systems that have a plethora of maintenance activities are wasteful and should be shortlisted for replacement.  You know the ones: solutions still running via on-premises VMWare software, software needing monthly java patching, and software if the wind blows the wrong way you have an unknown error.  These systems are ripe for replacement.  It can also be a compelling sell to executives.  For example, imagine going to the CIO and CEO of Acme corporation.  You highlight the Acme app is run by a staff of ten developers which fully loaded cost us about $250K each.  Therefore, developing, debugging, and maintaining that app costs our organization roughly $2,500,000 in developer time alone plus hosting fees.  You have analyzed this application and found that roughly 80% of the time, or $2,000,000, is spent on maintenance activities such as patching. You believe if the team were to rewrite the application in a modern programming language using a serverless technology approach the team could lower maintenance activities from 80% to 30%.  This means that the maintenance costs would decrease from $2 million to $750K each year.  Therefore, you can build a financial case that leadership fund a $1.25 million initiative to rewrite the application in a more supportable language and environment, which will pay for itself at the end of the second year.  No, I didn't get my math wrong -- don't forget that you're still paying the old costs while developing the new system.) Now if you just did a lift and shift to AWS and ran the servers on EC-2 or ECS, then you still have to patch the instance operating systems, middle ware, and software -- all of which is a non-value add.  This means that you won't reduce the maintenance activities from 80% to 30%.  Don't waste developer time on these expensive transition activities; you're not going to come out ahead.  Now let's instead look at how to make that maintenance go away by switching to a serverless approach.  Imagine if the organization rewrote the VMware application to run on either: A third party hosted SaaS platform such as Salesforce or Office 365 or A serverless AWS application consisting of Amazon S3 buckets to handle front-end code, an Amazon API Gateway to make REST API calls to endpoints, AWS Lambda to run code to retrieve information from a Database, and Dynamo DB to store data by the application This new software shift to a serverless architecture means you no longer have to worry about patching operating systems or middleware.  It also means developers don't spend time fixing misconfigurations and vulnerabilities at the operating system or middleware level.  This means you made the software more secure and gave the developers more time to write new software features which can impact the business profitability.  This serverless approach truly is better and more secure.  There's a great story from Capital One you can look up in our show notes that discusses how they moved from EC-2 Servers to Lambda for their Credit Offers Application Interface.  The executive summary states that the switch to serverless resulted in 70% performance gains, 90% cost savings, and increased team velocity by 30% since time was not spent patching, fixing, and taking care of servers.  Capital One uses this newfound developer time to innovate, create, and expand on business requirements.  So, if you want to make cheaper, faster, and better software, then focus on reducing maintenance activities that don't add value to the business. Let's recap.  World class CISOs create a world class software development organization.  They do this by focusing on cheaper, faster, and better software. To perform this function CISOs increase productivity from developers by creating documentation that teaches developers how to build software the right way as well as creating a training program that promotes secure coding practices.  World Class CISOs increase the convenience to developers by bringing high-confidence vulnerability lists to developers which means time savings in not weeding out false positives.  Developers live in Source Code Repositories such as GitHub or GitLab, not the ten different software security tools that security organizations police.  World Class CISOs remove waste by performing value stream exercises to lean out processes and make it easier for developers to be more efficient.  Finally, World Class CISOs make software better by changing the legacy architecture with expensive maintenance activities to something that is a winnable game.  These CISOs partner with the business to focus on finding systems that when re-architected to become serverless increase performance gains, promote cost savings, and increase developer velocity. We appreciate your time listening to today's episode.  If this sparks a new idea in your head. please write it down, share it on LinkedIn and tag CISO Tradecraft in the comment.  We would love to see how you are taking these cyber lessons into your organization to make better software for all of us. Thanks again for listening to CISO Tradecraft.  This is G. Mark Hardy, and until next time, stay safe out there. References https://www.sixsigmadaily.com/who-was-shigeo-shingo-and-why-is-he-important-to-process-improvement/ https://news.microsoft.com/speeches/satya-nadella-and-chris-capossela-envision-2016/  Galpin, T.J. (1996).  The Human Side of Change: A Practical Guide to Organization Redesign.  Jossey-Bass  https://www.businesscoaching.co.uk/news/blog/how-to-break-down-barriers-to-change  Ponemon Institute and IBM. (2017) The State of Vulnerability Management in the Cloud and On-Premises  https://www.bmc.com/blogs/what-is-shift-left-shift-left-testing-explained/  https://www.securecodewarrior.com/  https://www.securityjourney.com/  https://checkmarx.com/product/codebashing-secure-code-training/  https://owasp.org/www-project-benchmark/  https://docs.github.com/en/get-started/learning-about-github/about-github-advanced-security  https://medium.com/capital-one-tech/a-serverless-and-go-journey-credit-offers-api-74ef1f9fde7f 

  Episode 243 Billy is a Senior Developer working @ Next PLC in the Warehouse & Distribution Systems Team.   Links https://twitter.com/billydev5 https://billy-mumby-dev.com/ https://github.com/mumby0168   Resources https://discord.com/invite/qMXrX4shAv https://mumby0168.github.io/cosmos-event-sourcing-docs/ https://ievangelist.github.io/azure-cosmos-dotnet-repository/ https://github.com/IEvangelist/azure-cosmos-dotnet-repository https://devblogs.microsoft.com/cosmosdb/azure-cosmos-db-repository-net-sdk-v-1-0-4/   Videos https://www.youtube.com/watch?v=izdnmBrTweA https://www.youtube.com/watch?v=_rsVwc4n8Ps   "Tempting Time" by Animals As Leaders used with permissions - All Rights Reserved × Subscribe now! Never miss a post, subscribe to The 6 Figure Developer Podcast! Are you interested in being a guest on The 6 Figure Developer Podcast? Click here to check availability!  

Steph is joined by a very special guest and fellow thoughtboter, Rob Whittaker. ngrok (https://ngrok.com/) Time Off Book (https://www.timeoffbook.com/) Rob's Codespace Setup (https://github.com/purinkle/codespace) Rob Whittaker on Twitter (https://twitter.com/purinkle) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. And today, I'm joined by a very special guest and fellow thoughtboter, Rob Whittaker. Rob has been in the software business for the past 15 years and spent the last five and a half years at thoughtbot. Rob is the Director of Software Development for our Europe, Middle East, and Africa team and, in his spare time, likes to hunt down delicious beers and coffee. Rob, welcome to The Bike Shed. It's so lovely to have you on the show today. ROB: Thank you for having me. It's a pleasure to be here. Yeah, thank you for that lovely introduction and my far too complicated job title. It sounds more serious than it actually is. STEPH: Well, you do have a fancy job title, yeah, Director of Software Development. [laughs] ROB: Yeah, it's the added on bit where it's Europe, Middle East, and Africa where I feel like there's about 20 of us maximum. But that sounds more grandiose than it actually is. STEPH: Yeah, that's something that Chris and I haven't dug into too much on previous episodes are all the different teams that we have at thoughtbot. So the shorter way of saying that is Launchpad II, but not everybody knows that. But I'm going to circle back to that because I would love to talk a bit more about that specific team and the dynamic. But before we do that, I'm realizing I'm not familiar with your origin story as to how you came to thoughtbot and then how you became this very fancy grand title of Director of Software Development for Europe, Middle East, and Africa team. ROB: Yeah, there's a bit of history about thoughtbot London as well that kind of ties into this. So before thoughtbot Launchpad II, it was thoughtbot London before we went remote. And initially, we had the plan of setting up a new studio in London to help expand thoughtbot outside of the Americas, but that plan fell through. But he knew some people from another agency called New Bamboo, and so we merged with or acquired that agency, and that agency then became the thoughtbot London team. I'm actually the first hire or...not the first hire, that's not true, the first development hire for the thoughtbot London team that would then become launchpad II. I was at the Bath Ruby Conference six years ago, I guess. And there was just an advert up on the hiring board that Nick Charlton, who's a Senior Developer and Development Team Lead at Launchpad II now, had put up. And I saw it, and I was talking to somebody who was my mentor at the time that I'd worked with at a previous job at onthebeach.co.uk, a guy called Matt Valentine-House who now works at Shopify who, actually, fun fact, his face appears at the top of Ruby Weekly this week. If you open up this week's Ruby Weekly, you can see Matt Valentine-House, who said to me, "Yeah, apply for it, why not? You see what happens." And I was like, "Okay," and just kind of took the leap. So I thought, thoughtbot, why would thoughtbot want me? Which is something I think a lot of people think when they want to join thoughtbot. They think, well, I can't do that. But I would implore people to apply. And so, from there, I never really wanted to move to London. I'd always lived in the North West of the UK. I made that leap to London because I wanted to work at thoughtbot. And then, gradually, over time, the London team expanded, and we needed to split out the management roles, and the development director role came up. And I've always enjoyed the coaching side of software development. It seems that you gain more experience as you help people with less experience, and I've always enjoyed coaching. And that was a big part of the role for me. So I was fortunate enough to be allowed to do it. And then, from there, things have grown. Yeah, so it's been a really interesting journey as a development director. The London studio went through a pretty tough time at one point where not long after I became development director that two-thirds of the team, in the space of two weeks, decided to hand their notice in and unbeknownst to each other. And so, all of a sudden, we didn't have a very big team. We didn't have very many prospects, and so it was a tough time. And so it's really nice to look back on the last three years and go, okay, we came through that. We're now one of the stronger teams at thoughtbot. And somebody actually asked me in an interview the other day, somebody we actually hired, not just based on this question, but he said, "What is your proudest moment of working at thoughtbot?" And I was like, that's one of the best questions I've heard from a candidate. And I said, "Hmm, that's interesting." It's not anything development-related, but it's that I can now look back on this team and say this is the team that I have grown in my image and all these people apart from Nick, who was the person who put the advert of it at Bath Ruby. I've hired all these people, and so the buck stops with me really because if anybody isn't able to perform, then it's kind of my fault because these are the people that I want to grow into being the team and see be a successful product design team or product development team, which brings us to modern-day I guess. So yeah, that was a long origin story. That's pretty much my whole thoughtbot biography. And I apologize. STEPH: That was perfect. I thoroughly enjoyed hearing it. And yeah, that's an awesome question. What's your proudest moment, like, part of a team? That can yield so many insights. I love that question. And I love your answer as well in terms of this is the team. We've pulled through a hard time. And then we've built everybody to the point that they are now, which kind of leads in perfectly to my next question. So being the software development director, could you walk us through a little bit of like, that's one of those titles I feel like a lot of companies have, but they can be very different from company to company. Would you mind walking us through a bit of the day-to-day in the life of being a development director? ROB: Yeah, sure. It's one of those things where I think this is something that I'm not sure if it's unique to thoughtbot, but you end up taking on a lot of hats at thoughtbot. So I know you're a team lead. So you have to balance your responsibilities as an individual contributor, which is a term I don't like, but I haven't got a better way to say it yet, and your development team lead roles. And I have similar sort of responsibilities where I have to do my individual contributor work. I have to do my director work. I'm also on our DEI Council. So I have to add that work in too, and make sure it's balanced out. So the start of my day is very much about prioritizing things. I know you and Chris, a few episodes ago, had quite lengthy discussions about productivity systems and what tools Chris wants to use. And I'm a big fan of Things, and I've been using it for maybe ten years, if not more, that I've now got my system down that I'm able to prioritize things in the way that I can pick up the right task at the right time. So a big part of my day-to-day is figuring out what is the most important thing to work on? So I have my client work, and then it's about supporting the team from that point. And the big part of my idea of what a manager is is that my job isn't to tell you what to do; my job is to find out what you want to do and direct you in a place where you can find the answer. Or I can give you some guidance about where to find the answer. And I feel like I'm doing a bad job as a manager where if I have to act as a middle person. Because if somebody comes to me and says, "Oh, I want to do this thing," And I say, "Well, I'll talk to that person for you," and then come back, I have failed. And my job is to say, "Oh, you should talk to that person about this." And to some extent, it's about being lazy. I don't want to be doing too much stuff because I have other things to do. But I want to make sure that those people have the right frameworks and guidelines in place so that I can point them in the right direction. STEPH: I think the fancy term for that is just delegating. [laughs] ROB: Yes, thank you. [laughs] STEPH: But I like lazy. [laughter] I like that one as well. I love that framing of a manager where you're not telling someone to do, but as your job, you are helping that person figure out what they want to do and then supporting them. I've been chatting with Chris recently and some others because I've been reading the book Resilient Management by Laura Hogan. And it's really helped me cement the difference between mentorship, coaching, and sponsorship. And I realized that I'm already falling a lot into the coaching and sponsorship because mentorship can be wonderful, but it is more directive of like, this is what I've done. And this is what has worked for me, and you should do this too. Versus the coaching and sponsorship, I think aligns far more perfectly with what you described as management, where it is my job to figure out what brings you joy, what brings you energy, and then how to help you progress to your next goals and your next steps in your career. ROB: Yeah, I think Laura Hogan is a great resource like her blog posts and books. I haven't read Resilient Management. But I know that the team leads on my team had been on her training courses, and they say how great it is. And there's also a blog post of hers that's about managing in tough times. It has a much better title than that. But it's about how do we be good managers in such uncertain times when there are a lot of things going on around the world right now that we all have to deal with? And helping people deal with those situations. Because at the end of the day, work isn't the most important thing; the most important thing is living. And it's something I say to my team, especially when people feel like...it's something that I say to my team when they're not feeling well. The most important thing is that you get better. And thoughtbot is still going to be here. The most important thing is how you live your life and how you look after yourself, and everything else is secondary. STEPH: Absolutely. Well, and everybody needs something different from work too. Some people may be in a state where they really need more stability and predictability from their work. And some people may be in a space where everything else outside of work is very stable and calm, and then they want work to bring the challenge and the volatility and the variety to life. So I remind myself very often that not everybody wants the same thing from work and to figure out what it is that someone wants from work. And then your seasons change. You may be in a season of where you want stability, or then you may be in a season of like, I'm ready to grow and push and take some risks. So helping someone identify which season of work they're in. ROB: Yeah, I 100% agree. What people can't see is me nodding vigorously on the other side of this call. It's very much about understanding because everybody is different. And that's what we want from a good team; it's understanding everybody's different approach to things. And so sometimes people want the distraction of work because they don't want the time off to think about other things. They want to be able to sit and concentrate on something. And it's understanding different people. STEPH: Yeah, that's a great point. I'm curious; you mentioned that as part of being development director, you are also, in addition to managing the team and being part of DEI then, there's also your day-to-day client work. I think you've started a new client recently. Could you tell me more about that? ROB: Yeah, I'd recently been working for a client for two and a half years, which is a very long time to be working with one client at thoughtbot. And it came to the time where I was ready for a new challenge, and it was stable enough for me to move on. So I've been working for a company in the UK. They allow customers to buy and sell cars, not between customers, the customers like companies like Auto Trader but customers to dealers and back and forth. And primarily, they worked with buying cars. And they've launched a product in the UK where people can sell their cars as well because they found that 70% of people who are buying cars also want to sell their cars. And from there, they're now looking to expand into Germany and Spain, so we are helping them to do that. And it's an interesting project, not necessarily from a technical point of view, but I might come back to that but definitely from a cultural point of view. The product at the moment allows you to put in a license plate or a registration plate for a car. And there's then a service in the UK that will allow you to pull up the maker model and the service history of that car. But you can't do that in Germany because it's against the privacy laws to find something from registration plates. And so it's interesting these different cultural aspects that you have to take into account when expanding into other countries that you aren't from and that you have less knowledge about. Because I'm also aware that credit cards aren't a big thing in Germany either. So you have to think about how they pay for things in different countries. And the previous company I was working for they're based in the Middle East. And so we had to take into account how we would do right to left design in a mobile app, which is really interesting from a western point of view that you get so used to swiping through an experience from left to right. But then it's not just the screen that's right to left. The journey moves from right to left. So you have to get used to the transitions of the screen going the other way and not thinking of that as going backwards. It's one of the best things about working in this region is that we get to deal with so many different cultures and how they expect to use applications. It's really satisfying. STEPH: That's fascinating. Yeah, I haven't gotten to work on a project like that that has those types of considerations. I think the most relatable experience I have is more working in healthcare because that's one of those areas that I'm certainly not proficient. I've become more proficient because of the type of projects that I've worked on. But I'm curious, for expanding into other regions and cultures, do those teams typically have an expert on their team that then helps guide the development process? Or, as you mentioned, the process of buying a car could be very different in some of the legal aspects that you're up against. Is there someone that you can turn to that's then helping mentor or be aware of that process? ROB: Yes, the current client they have a team based in Germany, people who are from Germany that are advising us on different cultural aspects or legislative things. They are doing a lot of data analysis for us because we need a new service that we can use for looking up car details. Because there is a service that you give different information to to get information about the car back from. So yeah, we do have that team there. But that's not always the case because every client is different. The company that we're working for in the Middle East didn't have a team. They had two developers who were helping us. But we have to figure things out just from their cultural background to ask them questions about things and allow them to advise us, but nobody who was really a specialist. But that's an interesting thing as well, not just the cultural aspects of the customers but the cultural aspects of the company that you work for. We definitely found that the company in the Middle East was more hierarchical. And so that's another challenge that you have to work with because we tend to work in quite a flat way where we tend to default as on thoughtbot projects, of not having a point person on a project. Everybody is there to answer the questions. But some teams or clients want that point person. And so, we adapt and change to allow for that to happen and work in that way. But it is interesting to work in different companies as well as working as an agency. STEPH: Yeah, you bring up a really good point of something that I don't reflect on very often, but it's something that I really appreciate about our thoughtbot culture is that we do try to strive for a very flat hierarchy. But also in working with clients, we purposely will avoid like, if there are two or more thoughtboters on a project, we don't want one person that is then the primary contact between the client and the thoughtbot team. The goal is that everybody shows up. Everybody is part of the process; everybody is part of meetings. And we do have an advisor for projects, but otherwise, we work very hard to make sure that there's not just one person that's then responsible for communication. We want everybody to have opportunities to be part of meetings, to lead meetings, to take on initiatives versus having that one person. That is something that I really appreciate that we do. ROB: Yeah. And it's more noticeable when you go to places where that isn't the norm, and you appreciate it more. And I think a big part of that is how much we are trusted. And we trust people to trust us, I guess. STEPH: Yeah. And I think it fits in nicely with circling back to the management conversation is that when people have access to those opportunities, that makes my job so much easier as a team lead where then there are more opportunities to sponsor someone or to coach someone as to how they can then be the person that then takes on a project or if they want to lead a particular meeting, or if they want to help a team introduce retrospectives into their process. So it gives more opportunities for me to then coach someone into expanding their skill set in those ways. ROB: Yeah, that's interesting to think about, allowing yourself to coach other people in that role. Because as we gain more experience and become senior developers, we naturally fall into that role of taking the lead on projects, even when we're not asked to. But then, when you gain other responsibilities in the management track, so you as a team lead and me as a team lead and a development director, it could be better for you to not take that role and allow somebody else to come into that role so you can coach them. That's been playing on my mind the last couple of days. Josh Clayton, who's the Managing Director for one of our teams in the Americas, raised it on our pull request in our handbook where we were talking about team leads having a dedicated day to concentrate on team lead things. It's one of those things where somebody says something, and it's like, oh yeah, that really clicks. Maybe that's why we have been having certain struggles on projects where we need to rearrange things and learn from that and so we can be better on projects in the future. So that's something that really resonated with me, and it's flying around in the back of my mind at the moment. STEPH: Yeah, that really resonates with me because while the predominant part of being a team lead at thoughtbot is having one-on-ones with folks, I find that when I have more time, a lot of the work also falls outside of that one-on-one where it's following up on conversations around hey, this person mentioned they're really interested in growing their skill. How can I help them? How can I help find opportunities? Or I know that they're currently stretching their skill set right now. If I have some extra time, then I can check in with them. I can pair with them. I can see how things are going. So I find that while the one-on-ones are the staple thing that happens every two weeks, there's a lot of other behind-the-scenes work that's going on as well to make sure that that person is growing and feeling really fulfilled by their work. ROB: I know we've spoken a lot about the product side and the client side of working on the new project that I'm working on. There are some interesting technical sides to it as well. The client has found that they have had some issues with Haskell and running on M1 Macs. And so, they've decided to take the leap and use GitHub Codespaces as their primary development environment, which has been interesting. I had heard about it but only in the background. I hadn't read anything about it or hadn't had any direct conversations. I just heard that there was a thing. So it's been quite interesting to play with that. It's interesting the way the client is using it as well because they're using a Dockerized environment effectively inside Docker by using Codespaces. So you start the Codespace, which very basically is a Docker instance somewhere on GitHub's infrastructure. It's built very much for Visual Studio Code, and so you can just directly attach your Visual Studio Code session to the Codespace and go from there, but I'm a Vim user. I've started to feel like a bit of an old guard or a curmudgeon recently where I've been like; maybe I need to use Visual Studio Code. Maybe I should just unlearn my Vim key bindings and learn the Visual Studio ones. And people say, "Oh, you could just use The Vim key bindings in VS Code." I'm like, that's cheating. I spent the time to learn the key bindings for Vim. I will take the time to learn the key bindings for Visual Studio Code and use it for the way it's intended. So it's been interesting to understand how Codespaces works, not necessarily in the way, it's intended. So you can still SSH into a Codespace session, but then you lose all the lovely setup stuff that you might have on your local machine. So I did spend half a day porting my dotfiles which are based off thoughtbot's dotfiles, into something that Codespaces can use and made it publicly available. So if you go to github.com/purinkle/codespace, you can see what I use to set up my Codespace environment. And once that's set up, it becomes a bit easier because then you have all the things that you're used to running locally. It is very much early days for how the client is using it. And so they're really open to saying like, okay, let's find out what's not working, and let's work and figure out how to get it up and running properly. So one of the things we do find is that Codespaces do timeout after a while. And then you might lose, like, even if I've created a tmux session, that tmux session disappears. And so I have to go in and create it again. I'm not sure what the timeouts are. I haven't had time to look into what those timeouts are yet. But that's definitely the main pain point at the moment of it being used as a development environment. It's been interesting. It's been kicking around in the back of my head like the difference between developing locally and deploying locally. And it's something that I wanted to talk to people at thoughtbot and outside of thoughtbot as well to understand that more. Because I don't think you need everything running to develop locally, but you might need it to deploy locally. It's interesting to me to understand how different companies work on their products from that point of view. STEPH: Yeah, I'm selfishly excited that you are using Codespaces for a client project because I have kept an eye on it, and I'm very intrigued by it. But I also haven't used it for a project. And it sounds really neat. I'm curious, have you found that it has helped them with onboarding or if you need to switch from working on one application to another? Have you found that it has helped them with some of those? I'm guessing that's the problem that they're optimizing to solve is how do we help people run everything quickly without having to set it up locally? ROB: It's an interesting question because I don't have the comparison of trying to set up the environment as it was before. It was smoother. The main thing with access tokens because once you can set up your SSH keys and your GitHub tokens, it's just a case of running a script and letting it run. So yes, from that point of view, I can imagine if I tried to set up their previous environment, that it'd be a lot more challenging because they were using Vagrant and running things that way, which I know from experience would not be fun. And I know that my Mac fans would just be spinning all the time. It would be like an aeroplane was trying to take off. So I'm thankful for that, that I don't have that experience anymore that my machine is going to slow down all the time. We've had on a previous client who had a Dockerized environment, but you have to have it all running on your machine. There are pros and cons to everything with these things. And it's like you said, what is the problem they're trying to solve with introducing this setup? STEPH: Yeah, I can't decide if this is a good thing or a bad thing. But I'm also intrigued by the idea that if a team is using Codespaces, then that means everybody else is using VS Code. And you can still customize it so you can still have your own preferences. But that does set a standard, so everybody is using the same editor. There's a lot of cross-collaboration in terms of if you do run into an issue, then you can help each other out. Versus when I join other teams, everybody's using their preferred editor, and then there you may have a day where someone's like, "Oh, I'm really stuck because my particular editor is suddenly having a problem and can't connect." And then you have less people that are able to help them if they're not using that same editor. And I can't decide if I like that or if I hate it [laughs] in terms of taking away people's ability to pick and choose their editor. But then the gains of everybody is using the same thing which is nice and would be really great for pairing too. ROB: Yeah, that's an interesting point. I was talking to...I have a management coach. He's a PHP developer, and I'm a Rails developer. And we were talking about the homogenization of things nowadays. And is that good, or is that bad to use with stuff like RuboCop that lints everything, so it's exactly the same? Does that stifle creativity? But then, at the same time, the thing I like about Codespaces is I think we're biased coming at it from the point of view of Rails developers. And if you look at how you can use Codespaces in the browser directly from GitHub, that's quite interesting because now you're lowering the barrier to entry to get started and saying you don't need to have an editor. You don't have to set up everything. You can just do it from your browser. A few years ago, I used to volunteer or coach at an organization called codebar. They help people who are less represented in the tech community get represented in the tech community. And we would see a lot of people coming for sessions using...I forgot what it's called. What was it called? Cloud 66 or something. There was some remote development environment that people would come and say, "Oh, I've been using this," because they didn't know how to set up the necessary infrastructure to just get a Rails server going or things like that or didn't know how to set up Sublime or Atom or editor of choice. And it's really interesting if you remove your bias of 15 years of professional software development and go okay, if I were starting today, what would the environment look like, and how would I get started? I'm lucky enough that I've grown up with the web and seen how web development has changed and been able to gain more knowledge as it's appeared. I don't envy anybody who has to come into the industry now and suddenly have to drink from this firehose of all these different frameworks, all these different technologies. Yeah, I started off by just right-clicking and viewing source on HTML files back in 1998 or something ridiculous like that. And CSS didn't even exist or wasn't used. And so it's a much different world than 24 years ago. STEPH: That is something that Chris and I have mentioned on previous episodes where people are coming into software development, and as much as we love Vim and it sounds like you love Vim, our advice is don't start with Vim. Don't start there. You've got so much to learn. Start with something like VS Code that's going to help you out. And you make such a great point in regards to this lowering the barrier to entry. Because I have been part of a number of classes where you have people coming in with Macs or with a Windows machine, and then you're trying to get everybody set up. You want them to use the same browser for testing. And we spend like a whole class just getting everybody on the same page and making sure their machines are working or then troubleshooting if something's not. But if they can just go to GitHub and then they can run things seamlessly there, that's a total game-changer in terms of how I would teach a class, and it would just be far easier. So I hadn't even considered the benefits that would have for teachers or just for onboarding teams as well. But yeah, specifically for leading a class, I think that is a huge benefit. GitHub did some pretty cool stuff around when they were launching that as well because I went back and watched some of their GitHub Universe sessions that they had where they were talking about Codespaces. And one of the things that they did that I really appreciated was how they went about launching Codespaces. So initially, it was how fast can this be? Or what's our proof of concept? And I think when they were building this, they found it took about 45 minutes if they wanted to spin up an application and then provide you a development environment. And they're like, okay, cool, like, we can do this, but it's 45 minutes, and that's not going to work. And so then their next iteration, they got it down to 25 minutes, and then they got it down to 5 minutes. And now they've got it to the point that it's instantaneous because they're building stuff in the background overnight. And so then that way, when you click on it, it's just all ready for you. But I loved that cycle, that process that they went through of can we even do this? And then let's see, slowly, incrementally, how fast can we get it? And then, to get feedback, instead of transitioning their own internal teams to it right away, they created this more public club. I think they called it The Computer Club, something like that. And they're like, hey, if you want to be part of Codespaces or try out this new feature that we have, delete all the source and the things that you need locally, and then just commit to using Codespaces. And then, if you are stuck or if you have trouble, then your job is to let us know so then we can iterate, and we can fix it. I really liked that approach that they took to launching this product and then getting feedback from everyone and then improving upon it. ROB: Yeah, that sounds like an Agile developer's dream where you just put something out there that's the bare bones, and you're given license to learn from that experience and how people are actually using that tool. That's something we've actually tried to do on the client project at the moment is adding all the...now that there's a different flow in Germany, there are different questions we need to ask. And so that could be quite a complex thing to put into place. So what we said is what we're going to do is just put in the different screens, and all you have is one option to click. So you click that option, you go to the next one, go to the next one, go to the next one. Then we have something that the customer can click on and play with and understand, and then we can iterate on top of that. But it also allows us to identify areas of risk because you can go; oh, where does this information come from? But now we need to get this from a third-party service. So that's the riskiest thing we've got to work on here, where this other thing is just a hard-coded list of three-door or five-door cars. And so that's an easier problem to solve. So allowing yourself to put something that could be quite complex like GitHub Codespaces and go okay, we're going to put something out there. It takes 45 minutes to run-up. But we're telling you it takes 45 minutes to run it. We're not happy with it, but we want to learn how you're using it so that we can then improve it but improve it in the right direction. Because it might be that we get it to 20 minutes to start up, but you need it in half a second. That's a ridiculous example. Or it might be that you need to be able to use RubyMine with it instead of VS Code, and that's where the market isn't. That's the thing that you can't learn in isolation that you have to put something out there for people to use and play with. STEPH: There's one other cool feature I want to highlight that I realized that they offer as well. So in the past, I've used a tool called ngrok, which then you can make your localhost public so other people can access. You can literally demo what you're working on locally, and someone else can access it. And I think that it's very cool. It's come in handy a number of times. And my understanding is that Codespaces has that feature where they can make your localhost accessible. So your work in progress you can then share with someone, and I love that. ROB: Oh, that's really interesting. I didn't know you could do that. I know you could forward ports from your local machine to that. But I didn't know you could share it externally. That'd be really cool. I can see how that can be really helpful in demos and pairing. And it makes sense because it's not running on your computer. It's running on some remote architecture somewhere. That's interesting. STEPH: Well, that's the dream I've been sold from what I've been reading about GitHub Codespaces. So if I'm telling lies, you let me know [laughs] as you're working further in it than I am. But yeah, that was one of the features that I read, and I was like, yeah, that's great because I love ngrok for that purpose. And it would be really cool if that's already built into Codespaces as well. ROB: ngrok is really interesting with things like trying to get third-party services to work. So from, the previous client, they wanted an Alexa Skill. And so, if you're trying to work with an Alexa Skill, you have to sign in from Amazon's architecture onto your local machine. You have to use ngrok as the tool there. So I wonder if that could potentially solve a problem where if there are three developers trying to develop on this if you could point to one Codespace that you're all working on rather than... Because the problem we had was if me or Fritz or Rakesh was working on this, we'd have to go and then change the settings on the Amazon Alexa Skill to point to a different machine. Whereas I wonder if Codespasces allows you to have this entry point, you could point to like thoughtbot.codespace.github.com or something like that that would then allow you to share that instance. That's something interesting that I think about now. I wonder if you could share Codespace instances amongst each other. I don't know. STEPH: Yeah, I'm intrigued too. That sounds like it'd be really helpful. So circling back just a bit to where we were talking about wearing different hats in terms of working on client work, and then also working on the team, and then also potentially some sales work as well, I'm curious, how do you balance that transition? How do you balance solving hard problems in a codebase and then also transition to solving hard problems in the management space? How do you make all of that fit cohesively in your day or your week? ROB: The main thing that somebody said to me recently is that you can only do so much in a day, and it's about the order that you approach those things. And just be content with the fact that you're not going to get everything done. But you have to make sure that you work on things in the right order and just take your time and then work through them. I read a really good book recently that was recommended to me by my coach called Time Off. And it's all about finding your rest ethic, which sounds a bit abstract and a bit weird. But all it is it's about understanding that you can't be working 100% all the time. It's not possible. As developers, sometimes we can forget that we're creative people, and creativity comes from a part of your brain that works subconsciously. So it's important for you to take breaks throughout the day and kind of go okay; I use the Pomodoro Technique. So I have an app that runs, and every 25 minutes, I just take a little break. I don't use it in the way that it's supposed to be used. I just use it to give me a trigger to have a break every 25 minutes. And so in that time, I'll just step away from my computer. I'll walk to the kitchen, grab a glass of water. I usually have a magazine or a book next to my table. So I have a magazine here at the moment. I'll just read a page of that just to kind of rest my eyes, so they focus at a different level but also just to get my brain thinking about something else. And it seems counterproductive that like, oh, you're stepping out of what you were doing. But then I find like, oh, I suddenly have a little refresher to like, oh, I need to get back into what I was doing. I know where I've got to go. That thing that I was thinking about now makes a little bit more sense. And even if it's a bigger break, give yourself the license to go for a walk and just kind of clear your head. And a big thing about going for a walk is not to concentrate on completing the task of walking but to concentrate on the walk itself and taking the things that are happening around you. And let your mind just kind of...you'll sometimes notice that oh, I can hear a bird. But that bird's been chirping for five minutes, and you didn't notice because your mind's kind of going. And if you concentrate on, I just want to complete this walk, that's what I'm out here to do, then you lose that ability to let your mind reset. That's a big thing that I'm working on personally to concentrate on the doing rather than the getting done. And it ties into the craft of being a software developer because if you concentrate on the actual writing of the code and the best practices that we all believe in, you end up with something better that you don't then have to revisit at a later time. Where if you just try and get something done, you're just going to end up having to come back to it or have to revisit in some other way. I've actually got a blog post coming out soon about notifications on phones. I'm a big believer that your phone belongs to you and that if your work wants you to have work notifications on your phone, then they could buy you a phone just for that purpose. The only thing where I kind of draw the line is I have notifications for meetings on my phone because I can't think of another way to get those things to ping up at me. And I understand that there are jobs where you do need to have those sorts of notifications, especially things like where you're on call; it's a big thing. But when it comes to things where a manager wants to get a hold of you straight away, from a trust point of view, that's where I think things fall down. And you're questioning, like, okay, why does this person need to get hold of me at 7:00, 8:00, 9:00, 10:00 o'clock at night? And should I be available? We build by the day at thoughtbot. And so when I find, not when I find but when I talk to people, and they say, "Oh, I was still working at 7:30, 8:00 o'clock," I will say, "Why? You're devaluing your own time at that point because we're not billing any extra for that time. So you're making your craft and your skill...you're cheapening it. And I want them to relish the skills and competencies that they have. That's a big thing for me. We're very lucky at thoughtbot that we can draw a boundary at the end of the day and go, okay, that's it. There's no expectation for me. It is much more difficult at product companies. But yeah, I think it's something that as an industry, and it's a bigger thing as a society, especially with younger people coming into the industry who have never worked in an office and may never work in an office, that idea of where is the cutoff? For so much of the pandemic, the people I would get concerned about the most are the people whose beds I could see behind them because I'm thinking to myself, you spend at least 16 hours a day in that same room. And that's going to become the norm for people. And if people don't have those rest periods and those breaks and aren't given the opportunities to do that by their managers, then it's not going to end well. And happy people and fulfilled people do the best jobs from a business point of view. But that's never the way I approach it, but that's what I say to people. STEPH: I think that's one of the biggest mistakes that I made early on in my career, and even now, I still have to coach myself through it. It's like you said, we are creative people and people in software and in general and not just developers, but it's a creative craft. And I wouldn't step away to take breaks. I just thought if I pushed hard enough, I would figure it out, and then I could get done with my work because I was so focused on getting it done versus the doing, as you'd highlighted earlier. I haven't really thought about it in that particular light of focusing on this is the thing that I'm working on. And yes, I do want to get it done, but let's also focus on the doing portion of it. And so I wouldn't step away for walks. I wouldn't step away for breaks. And that is something that I have learned the hard way that when I actually gave myself that time to breathe, if I gave myself a moment to relax, then I would come back refreshed and then ready to tackle whatever challenge was in front of me. And same for keeping a magazine that's near my desk; I have found that if I keep a book or something that I enjoy...because, at some point, my brain is going to look for some rest, like, it happens. That's when we flip open Twitter or Instagram or emails or something because our brain is looking for something easy and maybe a little bit of like brain candy, something to give us a little hit. And I have found that if I keep something else more intentional by my desk, something that I want to read or that I'm enjoying, then I find that when I am seeking for something that's short that I can look at, that I feel more relaxed and fulfilled from that versus then if I go to Twitter, and then I see a bunch of stuff, I don't like, and then I go back to work. [laughs] And it has the opposite effect of what I actually wanted to do with my downtime. I love the sound of this book. We'll be sure to include a link in the show notes because it sounds like a really good book to read. And I've also worked on improving the setup with my phone and notifications, where I have compartmentalized all the work-related apps into one folder, and then I keep it on the third screen of my phone. So if I want to see something that's work-related, it's very intentional of like, I have to scroll past all of the stuff that matters to me outside of work and then get to that work section and then click in that folder to then see like, okay, this is where I have Slack, and Gmail, and Basecamp, and all the other things that I might need for work. And I have found that has really helped me because I do still have the notifications on my phone, but at least putting it on its own screen further away from the home screen has been really helpful. ROB: Do you find that you still get distracted by that, though, when you're in the flow of doing something else? STEPH: I don't with my phone. I am a person who ignores my phone really well. I don't know if that's a good thing or a bad thing, [laughs] but it is a truth of who I am where I'm pretty good at ignoring my phone. ROB: That's a good skill to have. If there's any phone in the room and a notification goes off, my head swivels, and I pivot, and I'm like, oh, yeah, some dopamine hit over there that I can get from looking at somebody else's notification. STEPH: I have noticed that in the other people that I'm around. Yeah, it's that sound that just triggers people like, oh, I got to look. And even if you know it's not your phone like you heard someone else's phone ding, it still makes you check your phone even though probably there's a part of your brain that recognizes like, that wasn't mine, but I'm still going to check anyways. And I have worked hard to fight that where even if I hear my phone go off, I'm like, okay, cool, I'll get to it. I'll check it when I need to. And I'm that person that whenever apps always ask me, "Can we send you notifications?" I'm like, no, you may not send me notifications. [laughs] Something else you said that I haven't thought about until just now is the idea that there are some people who have never worked in an office or may never work in an office because we are leaning into more remote jobs. And that is fascinating to me to think about that someone won't have had that experience. But you make such a good point that we need to start thinking about these boundaries now and how we manage our remote work and our home life because this is, going forward, going to be the new norm for a number of people. So how do we go ahead and start putting good practices in place for those future workers? ROB: One of the things, as we've hired people from a remote point of view who've only worked with thoughtbot remotely, is the idea of visibility. And I don't mean the visibility of I want to see when somebody's working but maybe the invisibility of people. Because you can't see when people are taking breaks, you assume that everybody is working all the time, and so then you don't take those breaks. And so this is something we saw with people who we hired in the first six months of being remote. And they were burning out because they didn't realize that other people were taking breaks. Because they didn't know about the cultural norms of how we worked at thoughtbot. But people who had worked in the studio would know that people would get up and have breaks. People would get up and go get a coffee from a coffee shop and then have a walk around. They didn't know that that was the culture because they bring the culture from other places with them. But then it's much harder to get people to understand your way of working and how we think that we should approach things when you are sat in isolation in a room with a screen. And that's something that we've had to say to people to break that down. And even things that we took for granted when we worked in a studio where somebody would get up and ask somebody if they could pair with them even if they weren't on the same project. Somebody might have more Elm knowledge or React Native knowledge, or Elixir knowledge. And you'd get up and say, "Hey, can I borrow some of your time just to go over this thing, to pair?" And everybody would say, "Yeah, yeah, I can find some time. If not now, we can do it later." And recently, we've had people saying, "Oh, is it okay if we pair across projects? Is it okay if we pair with other people?" It's like, "Yeah, pair." One of the big things we say is that we have this vast amount of knowledge across thoughtbot, across the world that we can tap into and that you can use. And that's just one example of how do you get those core things that you take for granted and help people understand them? Because you don't know what people don't know. And it's all about that implied knowledge. So that's something that we learned. And we try and say to people and instill in them about yeah, take breaks. You can pair with people. There are people who bring in culture from other places with them. But then, to go back to where you started, how do you start with people who have no culture with them or have the culture of coming from maybe from school, or university, or from a different industry? How do you help those people add to your culture but also learn from your culture at the same time? Big people problems. STEPH: Have you found any helpful strategies to normalize that take a break culture? ROB: One thing we tried, but it doesn't last very long because people are lazy, is putting it in Slack saying, "I'm going for a break." And you can do that, but it's so artificial. After a week or two weeks, people just stopped doing it. It was through conversation. We have a regular retrospective as the Launchpad II team where we talk about what is working, what isn't working. And we have such a trusting environment where people will say things along the lines of this isn't working for me, or I feel like I'm burning out. Then we will talk to each other about it and figure out where it comes from. And it's a good point to raise that I don't think we have explicitly addressed it. But it is something that we will address. I'm not going to say could address; we will address it. I will talk to our latest hire, Dorian, who I have a one-on-one with next week, and to kind of talk to him about it. And we should maybe try and codify that in our handbook somewhere so everybody can learn from it, at least start a strategy and a conversation. Because I don't think it is something that we do talk about. It's the problem of being siloed and being remote and time zones as well. A lot of stuff that Launchpad I knows Launchpad II doesn't necessarily know because we only have three, maybe, hours if people are based on the East Coast where we overlap. I have meetings with Geronda, who's our DEI Program Manager, and she lives in Seattle. And so sometimes I'll talk to her at 5:00 o'clock, and it's 7:00 o'clock in the morning for her. And you have different energy levels. But yeah, so we spend time to try and figure out how we work together. STEPH: Yeah, I like that idea of highlighting that we take breaks somewhere that's part of your expectations as part of your role. Like, this is an expectation of your role; you're going to take breaks. You're going to step away for lunch. You're going to stick to a certain set of hours in terms of having like an eight-hour workday with a healthy lunch break in there. I think that's a really good idea. On the Boost team, I have found that people have adopted the habit of not always but typically sharing of, like, "Hey, I'm stepping away for a coffee break," or "I'm having lunch. Maybe like a late lunch, but I'm taking it," Or "I am stepping away for a walk." You often see later in the afternoon where there are a number of people that are then saying, "Hey, I'm going for a walk." And I feel that definitely helps me when I see it every day to reinforce like, yes; I should do this too because I already admitted I'm bad at this. So it helps reinforce it for me when I see other people saying that as well. But then I can see that that takes time to build that into a team's culture or to find easy ways to share that. So just putting it upfront in like a role expectation also feels like a really good place to then highlight and then to reinforce it as then people are setting that example. ROB: One thing that Nick Charlton tried to introduce was a Strava group. There's a thoughtbot Strava group. So you can see if people are members of it that they've been walking and things like that. It was quite an interesting way to automate it. I think it fell off a cliff. But it was something that we did try to how can we make the visibility of this a little bit easier? But yeah, the best thing I've seen is, like you say, having that notification in Slack or somewhere where you can see that other people are stepping away from their keyboards. STEPH: Well, as you mentioned, solving people problems is totally easy, you know. It's a totally trivial task although I'm sure we could spend too many hours talking about it. All right, so I do have one more very important question for you, Rob. And this goes back to a debate that Chris and I are having, and I'd love to get you to weigh in on it. So there are Pop-Tarts, these things called Pop-Tarts in the world. And I don't know if you're a fan, but if you were given the option to eat a Pop-Tart with frosting or a Pop-Tart without frosting, which one do you think you would choose? ROB: That's an interesting question. Is there a specific flavor? Because I think that the Strawberry Pop-Tart I would have with frosting but maybe the chocolate one I have without. I know there are all sorts of exotic flavors of Pop-Tarts. But I think I would edge towards with frosting as a default. That's my undiplomatic answer. STEPH: I like that nuanced answer. I also like how you refer to the flavors as exotic. I think that was very kind of you [laughs] other like melon crushed or wild flavors that they have. Awesome. All right. Well, I think that's a perfect note for us to wrap up. Rob, thank you so much for coming on the show and for bringing up all of these wonderful ideas and topics and sharing your experience with Codespaces. For folks that are interested in following your work or interested in getting in touch with you, where's the best place for them to do that? ROB: Yeah, thank you so much for having me. It's been fantastic to have a chat. If people do want to find me, the best place would be on Twitter. So my handle on Twitter is @purinkle which I understand is hard for people to maybe understand via a podcast, but we'll put a link in the show notes so people couldn't find me more easily. And that's probably also a good time to say that I am actually trying to find a development team lead to join our Launchpad II team. So we are looking for somebody who lives in Europe, Middle East, or Africa to join our team as a developer and manager of two to three people. There's more information on the thoughtbot website, and I do tweet about it very, very often. So feel free to reach out to me if that's of any interest to you. STEPH: Awesome. We'll be sure to include a link to that in the show notes as well. On that note, shall we wrap up? ROB: Yeah, let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.