Podcasts about Software architect

For this episode, I spoke with David McCarter (@realDotNetDave), Software Architect, Code Quality Zar, and purveyor of DotNetTips.com, to discuss the misconceptions surrounding veteran engineers, and why and how youth-obsessed companies are failing to leverage their most experienced employees. You can find more information about my guest on my blog at https://buckleyplanet.com/

Today, we're diving deep into Semaphore's architecture with Radosław Woźniak, Software Architect at Semaphore. He's here to break down the inner workings of our CI/CD platform — from its 30+ microservices to how a simple git push triggers a series of interactions across Semaphore's infrastructure. Whether you're a contributor looking to understand the system or just curious about how Semaphore handles complex workflows, this episode is packed with valuable insights. Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.

In this episode of the Loco Experience Podcast, I welcomed Murph McIver into the Studio.  Murph is the Founder and Software Architect at Xeo Software, and moved his family from Honolulu to Fort Collins in 2021.  We discuss what brought them here, the unique attributes of Fort Collins, and the vibrant business culture. Murph shared insights into his company's founding story and mission to help businesses automate and scale, especially those that have unique needs that off-the-shelf software cannot address. We delve into the complexities and future of AI in software development, emphasizing its potential to level the playing field for custom software solutions. The conversation transitions to personal reflections, where Murph highlights his focus on lifestyle changes influenced by dandapani's book - “The Power of Unwavering Focus” and his personal commitment to making significant life enhancements through the power of concentrated thought.  I'm sure you'll enjoy, as I did, my conversation with Murph McIver.The LoCo Experience Podcast is sponsored by: Purpose Driven Wealth Thrivent: Learn more

Разбор резюме в прямом эфире. Разбираем CV программистов, которые хотят работать на американские компании. Frontend Software Engineer, Backend Software Engineer, Full Stack Engineer, Mobile Software Engineer, DevOps Engineer, Site Reliability Engineer (SRE), Machine Learning Engineer, Software Architect, Java Developer, Android, iOS Developer, Python, Django, Flask, JavaScript, React, .NET Developer, C# Engineer и так далее.Присылайте свое резюме для разбора в прямом эфире в телеграм канал https://t.me/prodcastUSA.Маша (Мария) Подоляк (Marsha Podolyak)Автор Телеграм канала "

Episode SummaryIn this episode of Maintainable, Robby sits down with Carola Lilienthal, Software Architect and Managing Director at WPS. Together, they explore the intersection of cognitive science and software architecture, strategies for tackling technical debt, and why simplicity, modularity, and domain knowledge are crucial for maintainability.Carola shares her approach to improving legacy systems, fostering domain-driven development, and introducing sustainable patterns into software design. She also discusses the Modularity Maturity Index (MMI), a tool her team has used to assess and improve over 300 systems.Topics Covered[00:00:43] What makes software maintainable?[00:01:24] The importance of clear structure, modularity, and simplicity in software.[00:02:38] How patterns help reduce complexity and onboard developers faster.[00:04:42] Addressing the challenges of systems with mixed architectural patterns.[00:06:20] Strategies for fostering creativity while maintaining simplicity.[00:07:05] How to guide teams to balance technical experimentation and maintainability.[00:14:03] Practical techniques for documenting architecture and decisions.[00:16:17] What is the Modularity Maturity Index (MMI), and how does it measure system health?[00:18:02] Common mistakes in managing technical debt and how to avoid them.[00:21:20] Why domain knowledge is essential for innovation and problem-solving.[00:33:03] Evolving legacy systems with domain-driven design and transformation.Key TakeawaysModularity matters: Simplified, modular systems with high cohesion and loose coupling reduce cognitive load and technical debt.Patterns as a shared language: Establishing a pattern language within your team creates consistency and eases onboarding.Cognitive science in software: Architecture aligned with how our brains process complexity results in more maintainable systems.Domain knowledge drives innovation: Teams should focus their creativity on solving domain-specific problems, not over-complicating the architecture.The value of architecture documentation: Keeping clear decision records helps teams navigate legacy code and onboard new developers.Resources MentionedCarola's LinkedInWPS WebsiteCarola's books:Sustainable Software ArchitectureDomain-Driven Transformation (English version coming soon)Modularity Maturity Index OverviewBooks Carola recommends:Reinventing Organizations by Frédéric LalouxTeam Topologies by Matthew Skelton and Manuel PaisBe sure to follow Carola on LinkedIn and X.Thanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Use the code maintainable to get a 10% discount for your first year. Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

  Francesco Iorio is the CEO of Augmenta, leading a team focused on AI, computational science, and user-centered design to revolutionize construction. The Augmenta Construction Platform uses generative AI to transform building design and construction, partnering with forward-thinking AEC companies like Interstates, Lighthouse Electric, and Miller Electric Company to boost productivity and optimize their electrical design process.   An Innovation Specialist, Research Scientist/Leader, Technical Manager and Software Architect, with a constant drive for innovation, business acumen and the ability to build and nurture extremely high-performing teams, together with excellent software development and project management skills.   Proven experience and a track record of innovation in multiple fields, with considerable technical and business impact.Expert knowledge of software architecture, strategic innovation, high performance systems, machine   learning, multi-threaded/multi-processor/distributed computing scalability issues, low-level systems performance optimization, signal processing, 3D computer graphics, low-latency and real-time programming and principles.   Expertise in designing and leveraging computing solutions ranging between small, low-power embedded systems, hybrid custom accelerators and GPUs, large-scale cloud-based software and supercomputers with several thousands of processors, and from fundamental research and custom software prototyping to customer-facing shipping products.   Initiation of and contributions to business development activities, client-facing strategic innovation sessions and presentations, academic partnerships and M&A activities.   Invited speaker and panelist at multiple high-profile scientific and engineering venues.Several awarded patents and numerous scientific publications in the field of computer science.   Show Highlights   Augmenta's innovative approach to automating building design to boost efficiency, minimize waste, and promote sustainability. Leverage artificial intelligence to automate and optimize building design processes, particularly in the construction industry. Reduce material waste and improve compliance with building codes through intelligent design solutions. Target customers: specialty subcontractors in electrical trades and engineering firms The Generative Design research program focuses on leveraging computational power to create optimized building designs. First building constructed using Augmenta's AI: public elementary school in rural Michigan. AI system trained on synthetically generated data and real-world projects. Collaboration and assembling diverse teams as key to success. “I have a virtue that I love to collaborate with people. Like for me, collaboration and surrounding myself with people who are even smarter and kinder than me is what I actually enjoy the most." - Francesco Iorio   Show Resource and Information Connect with Charlie Cichetti and GBES   GBES is excited our membership community is growing. Consider joining our membership community as members are given access to some of the guests on the podcasts that you can ask project questions. If you are preparing for an exam, there will be more assurance that you will pass your next exam, you will be given cliff notes if you are a member, and so much more. Go to to learn more about the 4 different levels of access to this one-of-a-kind career-advancing green building community!   If you truly enjoyed the show, don't forget to leave a positive rating and review on .  We have prepared more episodes for the upcoming weeks, so come by again next week! Thank you for tuning in to the !   Copyright © 2025 GBES

In this week's episode, we welcome back Sebastian Wagner, someone I really love catching up with and always learn a lot from. If you don't know Seb, he is the Founder of FlowRepublic and has coached 77 Salesforce CTAs through their journey from aspiring CTAs to passing the Review Board. Today, Seb shares information on his experience writing The Software Architect's Edge and shares insight into the Seven Mission-Critical Skills Needed to Become the Next Tech Superstar. You can find Seb on LinkedIn here: https://www.linkedin.com/in/se6wagner/ And of course, purchase his book here: https://www.amazon.com/dp/B0DM36DLYX   You can find more content from us at Talent Hub, here: LinkedIn@ https://www.linkedin.com/company/talent-hub-global/ YouTube@ https://www.youtube.com/@talenthub1140 Facebook@ https://www.facebook.com/TalentHubGlobal/ Instagram @ https://www.instagram.com/talenthubglobal/ Twitter X @ https://twitter.com/TalentHubGlobal We hope you enjoy the episode!

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview here:https://gotopia.tech/episodes/322Ashley Davis - Author of "Bootstrapping Microservices" & Principal Software Engineer at AutodeskDamian Maclennan - Technologist, Software Architect, Trainer, Developer & Consultant CTO at Stack MechanicsRESOURCESAshleyhttps://x.com/codecapershttps://www.linkedin.com/in/ashleydavis75https://www.codecapers.com.auDamianhttps://damianm.comhttps://mastodon.social/@damianmhttps://bsky.app/profile/damianm.comhttps://www.linkedin.com/in/damianmaclennanhttps://instagram.com/damianmaclennanhttps://twitter.com/DamianMLinkshttps://bootstrapping-microservices.comhttps://rapidfullstackdevelopment.comDESCRIPTIONDamian Maclennan, a software architecture and trainer, engages with Ashley Davis, author of “Bootstrapping Microservices", discussing the evolution and practical applications of microservices.With over 25 years of experience as a developer, Ashley shares insights into his career and what inspired him to write the book's second edition, emphasizing the importance of context in choosing the right architecture—be it microservices or monolithic systems—through examples like AI model processing and data security.They explore how industry trends, feedback, and advancements in tools have shaped the book, making complex concepts more accessible. Ashley and Damian highlight microservices' flexibility in system design, allowing for the gradual evolution and replacement of components, which helps manage technical debt and adapt to newer technologies.They emphasize that microservices facilitate smaller, focused teams that can independently manage and scale components, enhancing overall agility. However, they also caution against potential pitfalls, such as unnecessary complexity and improper implementation, which can undermine the advantages of microservices.RECOMMENDED BOOKSAshley Davis • Bootstrapping Microservices • https://amzn.to/3X8ccTcSarah Wells • Enabling Microservice Success • https://amzn.to/4aa8xrvSam Newman • Monolith to Microservices • https://amzn.to/2Nml96ESam Newman • Building Microservices • https://amzn.to/3dMPbOsSimon Brown • Software Architecture for Developers Vol. 2 • https://leanpub.com/visualising-software-architectureTwitterInstagramLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

GraphQL is an open-source query language for APIs and a runtime for executing those queries. It was developed by Facebook to address the problem of over-fetching or under-fetching data, which is a common issue with traditional REST APIs. Matt Bessey is a Principal Engineer and Software Architect. Earlier this year Matt wrote a blog post The post The End of GraphQL with Matt Bessey appeared first on Software Engineering Daily.

GraphQL is an open-source query language for APIs and a runtime for executing those queries. It was developed by Facebook to address the problem of over-fetching or under-fetching data, which is a common issue with traditional REST APIs. Matt Bessey is a Principal Engineer and Software Architect. Earlier this year Matt wrote a blog post The post The End of GraphQL with Matt Bessey appeared first on Software Engineering Daily.

Dein Update zur Digitalisierung der Versicherungsbranche. In dieser Folge des Digital Insurance Podcast spricht Jonas Piela mit Oliver Jung, Managing Consultant und Simon Eschner-Krauss, Software Architect bei Senacor. Senacor Technologies AG ist eine Unternehmensberatung mit knapp 1000 Mitarbeitern. Sie helfen bei der Business- und IT-Transformation. Der Fokus liegt auf Insurance, Automotive und Banking. FIDA steht für Financial Data Access. Der entsprechende Gesetzesentwurf der EU soll 2025 in Kraft treten. Es soll u. a. der Datenaustausch zwischen Finanzinstituten erleichtert werden. Damit ergeben sich für Versicherer neue Chancen am Markt, aber auch regulatorische Hürden. Das Ziel des Gesetzes: die Innovation und den Wettbewerb am Markt zu erhöhen. Bislang lag die Datenhoheit bei den etablierten Unternehmen, erklärt Oliver. Damit kleinere Unternehmen eine Chance haben und besser skalieren können, benötigen sie Daten. Das wird mit FIDA ermöglicht. Die DSGVO wird an keiner Stelle ausgehebelt, sondern steht stets über FIDA. Sensible Informationen wie Krankenversicherungsdaten dürfen gar nicht erst ausgetauscht werden. Für Versicherer sind die neuen Daten Gold wert. Sie können den Onboarding-Prozess vereinfachen oder für die Bestimmung eines Kundentarifs verwendet werden. Simon ist der Meinung, dass FIDA einen vergleichbar großen Impact wie PSD2 haben und die Geschäftsmodelle vieler etablierter Konzerne durcheinanderwirbeln wird. Links in dieser Ausgabe Zur Homepage von Jonas Piela Zum LinkedIn-Profil von Jonas Piela Zum LinkedIn-Profil von Oliver Jung Zum LinkedIn-Profil von Simon Eschner-Krauss

Witam w dwieście pięćdziesiątym ósmym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest to jak radzić sobie z legacy code dzięki GenAI.Dziś moim gościem jest Adam Witkowski – obecnie w Capgemini jako Software Architect. Wcześniej pracował w IT w bankach w Genui, Amsterdamie i Pradze. Zajmuje się tworzeniem Enterprise Risk Platforms dla banków inwestycyjnych oraz rozwiązań opartych na Generative AI. W wolnym czasie koduje Open Source na GitHubie.Sponsor odcinkaSponsorem odcinka jest Capgemini Polska.W tym odcinku o GenAI rozmawiamy w następujących kontekstach:czym jest i z czym kojarzy się legacy code?jak GenAI może pomóc w radzeniu sobie z zastanym kodem?czy na rozwiązaniach generowanych przez GenAI można polegać?czy takie rozwiązania są bezpieczne?czy rozwiązania agentowe wymagają posiadania w firmie potężnych maszyn?jaki jest poziom wejścia w te technologie?czy każdy projekt legacy nadaje się jako wsad do rozwiązań agentowych?czy programiści powinni się obawiać tego, że GenAI zabierze im prace?Subskrypcja podcastu:zasubskrybuj w Apple Podcasts, Spreaker, Sticher, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)poproszę Cię też o polubienie fanpage na FacebookuLinki:Capgemini Tech Talk – https://www.capgemini.com/pl-pl/aktualnosci/wydarzenia/tech-talk-meet-up-6-java/Profil Adama na LinkedIn – https://www.linkedin.com/in/adam-witkowski-6ba69513/GitHub – https://github.com/adamw7YouTube – https://www.youtube.com/watch?v=CEcUlnDpdW0Wsparcie:Wesprzyj podcast na platformie Patronite -https://patronite.pl/porozmawiajmyoit/Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.plhttps://porozmawiajmyoit.pl/258

In this episode of the JavaScript Master Podcast, we're thrilled to welcome Tomasz Ducin, an Independent Consultant, Software Architect, Speaker, Trainer, and Co-Founder of Architektura Na Froncie, based in Warsaw, Poland. Join us as we dive deep into the fascinating world of JavaScript generators! Tomasz shares why generators are an essential topic right now and breaks down the key differences between generators and regular functions. We'll explore how generators enable lazy evaluation in JavaScript, the difference between generators and iterators, and why understanding the iteration protocol is crucial for modern JavaScript developers. We also discuss the ECMAScript proposal for generators, its potential impact on the future of JavaScript, and what this means for the code we write today and tomorrow. If you're eager to master generators and boost your JS performance, this episode is for you! Tune in and uncover the "superpowers" of JavaScript generators with us!

Jenny Wanger is a product consultant and coach who loves to educate PMs around the world and is doing just that with her product operations course on Reforge. Her hot take? Product leaders send their teams off for training but then don't do anything when they come back, and nothing changes. This leads them to question the value of the training, but it's almost never the quality of the training that's at fault, it's what they (don't) do with it. Find Jenny on LinkedIn and remember to check out her course on Reforge. If you'd like to appear on Hot Takes, please grab a time! Related episodes you should like: The Role of Product Management on Truly Agile Development Teams (Allen Holub, Software Architect, Consultant & Outspoken Twitter Agilist) Survive the Feature Factory by Applying Product Thinking to Product Thinking (John Cutler, Product Evangelist & Coach @ Amplitude) Escaping the Build Trap with Product Operations and Strong CPOs (Melissa Perri, Product Management Leader, Educator & Author "Escaping the Build Trap") OKRs: The Gateway Drug to Agility & Good Product Management (Jeff Gothelf, Product Management Consultant & Co-author "Lean UX" ) The Five Dysfunctions of Product Management Teams (Saeed Khan, Founder @ Transformation Labs) Going Beyond the Dreaded Product Demo and Creating the Perfect Sales Pitch (April Dunford, Author "Obviously Awesome" and "Sales Pitch") Enabling Strategic Product Decisions through Product Operations and Portfolio Management (Becky Flint, CEO of Dragonboat) Transforming your Organisation to the Product Operating Model (Marty Cagan, Author "Inspired", "Empowered" and "Transformed")

In this episode of Two Zero Q – 20 Questions With Interesting People, we learn the ‘Origin Story' of Sonyl Nagale - From Iowa born violinist to JavaScript for American Idol voting to Software Architect in New York City.Join me, The Very Handsome Tim Kirk for Two Zero Q – 20 Questions With Interesting People, where we learn the ‘Origin Stories' of everyday Superheroes in the LGBT Community and Friends!#twozeroq #theveryhandsometimkirk #pride #lgbt Get bonus content on Patreon Hosted on Acast. See acast.com/privacy for more information.

How did you become a software architect?

What are the qualities of an excellent software architect?

Ori Saporta, co-founder and Systems Architect at vFunction, joins host Jeff Doolittle for a conversation about the role of the software architect. The episode begins with Ori's thoughts on what is typically missed or overlooked regarding this role. The conversation then explores aspects of both hard and soft skills required of software architects. Other topics include the relationship of the software architect to other roles, to design and process, and to quality. The show concludes by addressing the importance of dependency management by software architects. Brought to you by IEEE Software magazine and IEEE Computer Society.

В LTE №28 — всё, что вы хотели знать и боялись спросить про карьеру архитектора. От того, как им становиться и зачем (в частности, спасет ли это вас, если сеньором быть уже тесно, а в тимлиды не хочется). До того, куда двигаться, став software architect, каким пламенем вы можете выгорать и как в крайнем случае вот это вот все это развидеть.  Кто: Анна Мелехова, Software Architect & Software Development Group Manager в KasperskyOS - собственной микроядерной операционной системе Лаборатории Касперского Про что: Какие бывают архитекторы и что у них за роли. Как понять, нужны ли архитекторы в вашей компании и что делать, если ответ “не нужны”. Как стать архитектором: классический путь и “а можно ли по-другому?” Что делать, если вы им наконец стали, и точно ли вы окажетесь рады. Когда и как правильно уходить (в том числе как легко прогадать при переходе в другую компанию). Сообщение LTE № 28. Карьера Software Architect появились сначала на linkmeup.

In today's episode, we welcome John Crickett, veteran software engineer, having worked at Staff, VP, and C-Suite positions over the years, and now focusing on helping thousands of engineers worldwide, through his coding challenges that have you building real applications, as well as helping with the soft skills through his articles and posts about software development. Today we cover a LOT of ground where we explain exactly what a Software Architect is, discuss different leadership types, advice to get a software job, remote work, unpopular opinions on programming languages, performance and scale, and a couple other things, so stay tuned because this episode is a true fountain of knowledge. Learn back-end development - https://boot.dev Listen on your favorite podcast player: https://www.backendbanter.fm John Crickett's Twitter/X: https://twitter.com/johncrickett John Crickett's Linkedin: https://www.linkedin.com/in/johncrickett/ Coding Challenges: https://codingchallenges.fyi/ Coding Challenges on Substack: https://codingchallenges.substack.com/ Research mentioned at 27:33 : https://www.researchgate.net/publication/232514133_Effect_of_self-differentiation_and_anonymity_in_group_on_deindividuation More on the topic of Deindividuation: https://en.wikipedia.org/wiki/Deindividuation#Major_empirical_discoveries Timestamps: 00:12 Who is John Crickett01:13 What is a Software Architect03:04 People vs Technical Leadership03:53 What kind of decisions does a software architect make?04:43 Is there a lot of "Thought Leadership" involved?05:23 Do you prefer Technical or People leadership?07:47 How did John start his coding career?11:39 Most people don't start working at "sexy" companies13:58 Juggling off-topic14:32 What are the Coding Challenges?19:03 Remote work and downtime22:56 The wrong culture might spoil the remote environment and people care less about the work27:05 Anonymity turns people into assholes29:58 Why did we have a phone call when this could've been an e-mail?33:42 Doing LeetCode vs Building Projects36:54 Most of the time you'll be using already existing solutions40:05 Is there too much abstraction nowadays?41:56 Using the Command Line is cool again!43:44 When talking about scale, what matters most is the architecture, not the language or framework51:30 Why just switching to a "faster" language isn't enough53:48 Go vs Rust performance comparison54:44 Learning how to write performant code is more important than the programming language itself55:25 The importance of benchmarking58:33 Where to find John

Gregg’s career includes over 30 years of multifaceted experience with a proven track record of architecting global large scale highly available consumer facing solutions in agile ways. He is recognized as a Technical Specialist by Ford Motor Company and held roles ranging from Developer to Architect. Most recently he has applied an Architect perspective while … The post 257 Being a Software Architect, with Gregg Ubben first appeared on Agile Noir.

Growing in your career can look differently for everyone. One may take on the challenge of managing others, helping to mentor and foster a culture of learning, while others may rise to the challenge of being an individual contributor taking on more responsibilities.  We like to ask our teammates, how can you maximize the impact you can make? Martin Kostov, a Software Architect, is a great example of a teammate who has embraced learning at every phase of his career. He tried the manager path and then made a pivot to work more with our technology as an architect. In his ten years at DraftKings, Martin has seen so much growth; not just with our products with the addition of new features, apps, and technologies - but within his own skills as well.  Martin joins the DraftKings Life podcast to walk us through some of his most exciting projects and why he enjoys working with our technology. If you're looking to learn more, Martin has published a few articles on our DraftKings Engineering Blog. You can check out our open opportunities as well.   

My name is Jeremy Miller and I am a Developer and Software Architect in Austin, TX. I started my career as a “real” engineer and got into software development writing automation tooling for my engineering group. This being the late 90's, it was easy to transition into the early project automation groups where I got to be part of several initiatives to automate large construction project workflows. I was able to turn that experience into a real programming job at a Fortune 500 company. After a couple years of slogging through old style waterfall development, I discovered Agile Software Development and have mostly stayed in that world ever since. I was at the forefront of early Agile usage in .Net and for better or worse was one of the main folks behind the short-lived ALT.Net movement. I've also been very active in .Net OSS development starting with the old StructureMap library and on to many other projects since. I'm currently the lead developer on the Marten project. Since then I've swung between product shops and consulting companies before starting with MedeAnalytics this year heading up their new software architecture team. You can find Jeremy on the following sites: Twitter Website Here are some links provided by Jeremy: Critter Stack PLEASE SUBSCRIBE TO THE PODCAST Spotify Apple Podcasts Google Podcasts Amazon Music RSS Feed You can check out more episodes of Coffee and Open Source on https://www.coffeeandopensource.com Coffee and Open Source is hosted by Isaac Levin --- Support this podcast: https://podcasters.spotify.com/pod/show/coffeandopensource/support

Are you fascinated by the intricate dance of technology and innovation? Do you dream of shaping the digital landscapes of tomorrow? If so, you're in the right place! In today's episode, we're diving into the world of software architecture—a dynamic and rewarding field at the intersection of technology and innovation. From shaping the digital landscapes of tomorrow to leading teams and projects, software architects play a pivotal role in designing and implementing cutting-edge software solutions. So, whether you're a seasoned professional or an aspiring technologist, join us as we unravel the intricacies of this fascinating career path.Connect With Mehttps://linktr.ee/studyabroadacademyWhat You May Learn:0:00 Introduction1:09 Mission Statement2:00 Scope3:24 Nature of Work4:10 Skills & Educational Qualification5:26 Salary6:55 7 Steps Template to be a Software Architect10:34 ConclusionSupport the show

Without a doubt, many conversations are being had globally on artificial intelligence (AI), and one of the most important occurred during the recently held Annual Meeting of the World Economic Forum in Davos-Klosters, Switzerland. Software Architect and Tech Entrepreneur, Joel Dean, who attended the meeting, joins us on this episode and shares with us:    *  the AI-related issues that were discussed at Davos;    *  important takeaways he had from those discussions; and   *  how we, in the Caribbean (and perhaps more broadly developing countries), should be positioning ourselves for AI and the future of tech.   The episode, show notes and links to some of the things mentioned during the episode can be found on the ICT Pulse Podcast Page (www.ict-pulse.com/category/podcast/)    Enjoyed the episode?  Do rate the show and leave us a review!     Also, connect with us on: Facebook – https://www.facebook.com/ICTPulse/  Instagram –  https://www.instagram.com/ictpulse/  Twitter –  https://twitter.com/ICTPulse  LinkedIn –  https://www.linkedin.com/company/3745954/admin/  Join our mailing list: http://eepurl.com/qnUtj    Music credit: The Last Word (Oui Ma Chérie), by Andy Narrell Podcast editing support:  Mayra Bonilla Lopez   ---------------- Also, Sponsorship Opportunities! The ICT Pulse Podcast is accepting sponsors! Would you like to partner with us to produce an episode of the podcast, or highlight a product or service to our audience? Do get in touch at info@ict-pulse.com with “Podcast Sponsorship” as the subject, or via social media @ictpulse, for more details.   _______________ 

Gregor Hohpe, author of "Enterprise Integration Patterns", talks to Dave Farley about software architecture and how architects can transform businesses. They chat about: Gregor's current role and work with AWS (Amazon Web Services), the challenge of finding new architectural models in the cloud, "Gregor's Law" AND MORE! Thanks to Gregor for joining Dave on this episode of the Engineering Room. xxJOIN PATREON HERE ➡️ https://bit.ly/ContinuousDeliveryPatreon

In this episode of "The Engineering Room", Dave Farley talks to Hannes Lowette and Simon Brown. Simon is the creator of the C4 Model and author of "Software Architecture for Developers". Simon, Hannes and Dave have a wide-ranging discussion about Software Architecture: how to do 'just enough' up-front design; why most teams should NOT do Microservices; learning to be a Software Architect; and, the impact of Modern Software Engineering. Thanks to GOTO, who recorded this conversation at their Conference in Copenhagen - check out their links below.xx

Dave Singer is Verint's Global Vice President, Go-To-Market Strategy. Singer is responsible for driving the GTM strategy for Verint's Workforce Engagement solutions, and the Verint industry leading Open CCaaS Platform. The strategy is based on developing innovative messaging and offerings both partner and direct that drive customer centric differentiation and aligned value with both customer needs and expectations.   Singer joined Verint in 2002 and has held a variety of roles in Verint including Director of Solution Consultants, RVP of Solution Principles, and most recently RVP, Presales, focusing on Solution Consulting and Innovation. Prior to Verint, Dave was a Principal at eLoyalty and a Software Architect at IBM.   Questions We always like to give our guests an opportunity to share in their own words a little bit about your journey, how it is that you got from where you were to where you are today? What is Verint? And what does Verint do? What would you say are maybe two or three overarching themes or pain points that your customers predominantly have challenges with as it relates to closing that customer engagement gap? What do you think are maybe two things if your clients came to you and asked where do you think we need to be putting our focus for 2024 to kind of set ourselves apart from the competition and really be able to supersede our customers' expectations?” What would those two things be based on your experience, as well as maybe what the data is actually telling you? Could you also share with our audience what's the one online resource, tool, website or app that you absolutely can't live without In your business? Can you also share with us maybe one or two books that you've read that has had a great impact on you? It could be a book that you read recently, or even one that you read a very long time ago, but it has had a great impact on you. Can you also share with our listeners what's the one thing that's going on in your life right now that you're really excited about? Either something you're working on to develop yourself or your people. Where can listeners find you online? Now, before we wrap our episodes, we always like to ask our guests, do you have a quote or saying that during times of adversity or challenge, you will tend to revert to this quote if for any reason you get derailed or you get off track? The quote kind of helps to get you back on track. Do you have one of those? Highlights Dave's Journey  Me: I know we read a little bit about your background in the bio that I just read. But we always like to give our guests an opportunity to share in their own words a little bit about your journey, how it is that you got from where you were to where you are today?   Dave shared that he'll go to beginning to now, the opposite order of the quick CV Yanique read. So, as was said, he started out life as a Software Engineer and after a little while, he realized he could have more impact on more customers and more people if he moved from just building one piece of code to consulting with organization, how do you use technology to improve their customer service and improve their operations.  He did that for a while, then he moved over to Verint and he really felt that Verint had a great set of applications and tools to do exactly that. And so, moved through there, again, continue to help customers deliver better experiences, their (Verint) customers better experiences for their customers and their employees. And his move to go to market strategy a few years ago, it was really a great opportunity for him to be able to, again, step back from looking at individual brands or individual opportunities and look at more holistically, how can Verint help all brands, how can Verint help all of their customers really help deliver better customer service, better agents, and employee experiences, and without sounding too, too corny, but really, really help people.    What is Verint and What Do You Do? Me: Now, could you also tell our listeners, what is Verint? And what does Verint do?   Dave shared that Verint is the customer engagement company, and they're focused on helping brands elevate customer experience while also reducing costs and improving efficiency. So, the core problem in the market they set out to solve is something they call The Engagement Capacity Gap. So, if you think about it, customers, consumers, their expectations are going up and up and up and up all the time as there are more channels, more modalities, more ways that consumers can interact with brands, their expectations, the number of contacts go up, and their expectations go up.  One of the things he thinks is really interesting is that people are now expecting online speed of service in the real world. So an example he uses a lot is, it's different on the experience, if you go to a store, you see something you like maybe it's the colour you want is out of stock, or the price is too high. So you can scan it on your phone, and have it delivered for an online retailer before you get home.  So, that kind of intersection of the real world and the digital world drives incredible expectations increase. And the problem brands have is that they have relatively flat budgets and resources to meet these expectations, that's incredibly hard.  So, what Verint does is delivers they call “CX Automation Capabilities or Customer Experience Automation”, ways they can help the employees of brands meet these expectations without having to do exponential increases in hiring. So, what they do is they help their customers engage better with their consumers to meet their expectations in the most efficient and productive and deliver great experiences across the board.   Overarching Themes or Pain Points that Your Customers Have Challenges With  Me: Based on your experience, Dave, in the customer engagement space and the different customers that you work with, what would you say are maybe two or three overarching themes or pain points that your customers predominantly have challenges with as it relates to closing that engagement gap?   Dave shared that he looks at from one pain point any two dimensions. One is, from the customer perspective, it's interesting, the common belief used to be channel switching is bad, you should deal with customers and solve their problem with a channel they first reach out on. But that's changing, customers and consumers want to change channels at their own direction, right. So, you may start with an email then flip to chat, then call in, then follow up of an email, that's fine, that's how consumers want to interact, especially since all of those channels now land on your smartphone, it's not like you're moving to a different device per channel.  And that creates a real challenge for brands to be able to manage all these channels in a completely seamless way so that customers aren't repeating themselves every time they connect. And then on the flip side, the challenge for employees is, theme probably come up a few times here is great employee experiences are necessary for great customer experiences.  If your employees are disengaged and stressed out and don't have the tools they need, then they're poor experience is going to just seem is going to translate to poor customer experiences.  So, he thinks brands really struggle with how do you manage the customer need for seamless interaction and continuity of interaction across channels, while also providing the engagement, the tools and the experiences for their employees that allow them to deliver great experiences to customers when they interact.    Things an Organization Needs to Focus on to Set Themselves Apart From the Competition and Supersede Their Customers' Expectations  Me: Now Dave, we are basically closing out 2023 and we're embarking on a new calendar year, lots of things happening across different industries throughout the globe. What do you think are maybe two things if your clients came to you and said, “Dave, as the subject matter expert in this area, where do you think we need to be putting our focus for 2024 to kind of set ourselves apart from the competition and really be able to supersede our customers' expectations?” “What would those two things be based on your experience, as well as maybe what the data is actually telling you?”   Dave shared that there's a couple of things, they're both related. He would classify 2023 as the year of experimenting with AI, Gen AI and Chat GPT, and Open AI, all that really hit the world in a big way, Novemberish of 2022.  And through this year, a lot of brands are experimenting with how do we use this to deliver better content, deliver better answers, support our customers better, but it's very much been a year of experimentation.  He thinks 2024 is the year where that has to get operationalized. Brands need to look at, “Okay, we've experimented with this for year, we've done some trials, next year is the year to make that drive value for us.” is one thing.  The second thing, he thinks this is really important. And this is core to the ethos of a Verin is think about employee and human augmentation, not replacement. So, for a long time, there's been this belief or this talk track that, “Hey, if we get the right Chatbots and the right RPA and the right tech in place, we won't need people anymore, we can automate that away.” And he doesn't believe the data shows us, that's not the case. There are things that humans are better at than machines, at a certain level of complexity and value and emotional importance, humans want to speak to humans. So, he thinks the focus of AI and automation, and we're very focused is our delivery of CX automation is really around human augmentation, because that gives the employees the power and the great experience that lets them help customers in a better way. So, 2024 is going to be the year of getting value from AI versus experimenting and pivoting from human replacement to human augmentation with CX automation.   App, Website or Tool that Dave Absolutely Can't Live Without in His Business When asked about online resource that he can't live without in his business, Dave shared that there is so many, for them he'd say broadly it's access to knowledge that comes in a few different ways.  So, it's the ability to do research on the internet in general and is to get access to broad information. And he thinks right now, looking at some of the Gen AI and the rag tools that let us turn that information into knowledge to get answers faster.   So really, for him, it's all about getting to answers, so any of the any of the online tools that allows for knowledge retrieval quickly. And again, we have knowledge management solutions and wiki solutions, things like that. But to him, it's all about access to knowledge and answers quickly.   Books that Have Had the Biggest Impact on Dave When asked about books that have had a great impact, Dave shared that Outside In: The Power of Putting Customers at the Center of Your Business by Harley Manning is a great book, it's a classic that always reminds us to focus, look at things from the customer perspective, and design our solutions and our tools, our processes, from the point of view of the customer, not the point of view of what we as a company, or we as a brand want to do. That's one of being pivotal in how he thinks about things.  Another one that he thinks is great just from a business strategy book is What Got You Here Won't Get You There: How Successful People Become Even More Successful by Marshall Goldsmith. So again, it reminds us that things change, that things change increasingly quickly. So, we always have to be evaluating our strategies and our approaches and our solutions to adapt to where we are right now and where we want to get to.  And just because a pattern worked for us last year, doesn't mean it's going to work this year, doesn't mean throw it away. But you just can't have that assumption that doing the same thing over and over again, is going to keep having the same results going forward.  So, he would just look at those two and ones he read both a while ago, but come back to all the time, the focus on customer perspective first and always evaluate are your strategies effective right now? Not were they effective last year is really important.   What Dave is Really Excited About Now! When asked about something that he's really excited about, Dave stated that first he's going to share something completely unbusiness related, personal that he's excited about that he'll bring it back. So, his daughter just started college this year and he's really excited to watch that process of her learning and growing and moving from a kid in high school to a to a young woman in college and getting ready to meet the world. So, he thinks it's first aside from the fact he's just so proud of her, it's just really exciting to watch and remember what that development looks like and feels like and how to take that forward.  The other thing if anyone has seen him on video sometimes, his office, he has martial arts weapons all over his office, he's been training that for a while. He's currently training for his next rank, which is exciting for him personally. But one of the core concepts in martial arts is something called beginner's mind, which says no matter how advanced or experienced you get, you can never forget that you're always the beginner at something. There's always more to learn about the basics. And every time he looks at training for a level or a promotion, it reminds him when he comes back to work that, “Hey, I always have more to learn, right. There's always something to pick up from even things I've done 1000 times.” So again, he thinks that's a really important mindset going forward. And it's something he reinforced with his teams all the time is, just because you think you know, doesn't mean you know.  Just because you're good at something doesn't mean you couldn't be better. Just because someone does something differently in the way you do it doesn't mean it's worse, it just means it's different, it's something to learn from that. So, he thinks bringing that concept of beginner's mind back and keeping that, it keeps you humble, and keeps you open to getting better every day.   Me: Yeah, those are really good points. Awesome.   Where Can We Find Dave Online Website - www.verint.com LinkedIn - https://www.linkedin.com/company/verint X - @Verint Facebook - https://www.facebook.com/verint LinkedIn – David Singer   Quote or Saying that During Times of Adversity Dave Uses  When asked about a quote or saying that he tends to revert to, Dave shared that it's not so much a quote but he just believe there's always a path forward. “And just because you don't see the path in front of you right this second, doesn't mean it's not there.” So, for him, when things get tough, he just remember that just because he doesn't see the path right now, doesn't mean if he doesn't take two steps forward, he's going to break through the trees, it's going to be right there. So, holding on to that fact is how he gets through adversity or when times maybe aren't turning the way he thinks they are.   Me: So, there's always a path forward. Alright, thank you so much for sharing Dave. Well, Dave, just wanted to say thank you very much for taking time out of your very busy schedule, and hopping on our podcast and sharing a little bit about your journey, as well as what you do at Verint and the great value that Verint is bringing as it relates to customer engagement and closing that gap for the many different organizations and customers that you work with. And also some of the things that organizations should try to focus on for 2024 as we really try to utilize all of the different knowledge sources, and technology opportunities that have been presented to us in a way that really helps to exceed the customers' expectations and even give them what they need or want before they even know that they need it or want it, so really enjoyed the conversation and I just want to express our deepest gratitude to you.   Please connect with us on Twitter @navigatingcx and also join our Private Facebook Community – Navigating the Customer Experience and listen to our FB Lives weekly with a new guest   Links •     Outside In: The Power of Putting Customers at the Center of Your Business by Harley Manning •     What Got You Here Won't Get You There: How Successful People Become Even More Successful by Marshall Goldsmith   The ABC's of a Fantastic Customer Experience Grab the Freebie on Our Website – TOP 10 Online Business Resources for Small Business Owners  Do you want to pivot your online customer experience and build loyalty - get a copy of “The ABC's of a Fantastic Customer Experience.” The ABC's of a Fantastic Customer Experience provides 26 easy to follow steps and techniques that helps your business to achieve success and build brand loyalty. This Guide to Limitless, Happy and Loyal Customers will help you to strengthen your service delivery, enhance your knowledge and appreciation of the customer experience and provide tips and practical strategies that you can start implementing immediately! This book will develop your customer service skills and sharpen your attention to detail when serving others. Master your customer experience and develop those knock your socks off techniques that will lead to lifetime customers. Your customers will only want to work with your business and it will be your brand differentiator. It will lead to recruiters to seek you out by providing practical examples on how to deliver a winning customer service experience!

“Everything in software architecture is a trade-off, and the why is more important than how." Today's clip is from Tech Lead Journal episode 120 with Neal Ford, a Director and software architect at ThoughtWorks. In this clip, we discussed the definition of software architecture and how it relates to software design. Neal then described the two important laws of software architecture related to trade-offs and the why. Neal then explained why software architecture is difficult and discussed the hard parts.   Listen out for: Definition of Software Architecture - [00:00:26] Software Architecture vs Design - [00:04:06] Laws of Software Architecture - [00:06:01] The Hard Parts of Software Architecture - [00:10:33] _____ Neal Ford's BioNeal Ford is Director, Software Architect, and Meme Wrangler at ThoughtWorks. He is also the designer and developer of applications, articles, video presentations, and author and/or editor of an increasingly large number of books spanning a variety of subjects and technologies, including the two most recent Fundamentals of Software Architecture and Building Evolutionary Architectures. His professional focus includes designing and building of large-scale enterprise applications. He is also an internationally acclaimed speaker, speaking at over 700 developer conferences worldwide, delivering more than 3000 presentations. Follow Neal: Website – nealford.com Twitter – @neal4d _____ Our Sponsors Are you looking for a new cool swag? Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available. Check out all the cool swags available by visiting techleadjournal.dev/shop. And don't forget to brag yourself once you receive any of those swags. Like this episode? Show notes & transcript: techleadjournal.dev/episodes/120. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.

In this podcast Michael Stiefel spoke to Sid Anand about what it means to be a software architect, the process of becoming one, and how to be a successful architect in an organization. Read a transcript of this interview: https://bit.ly/3R3KT8l Subscribe to the Software Architects' Newsletter [monthly]: www.infoq.com/software-architect…mpaign=architectnl Upcoming Events: QCon London https://qconlondon.com/ April 8-10, 2024 Follow InfoQ: - Mastodon: https://techhub.social/@infoq - Twitter: twitter.com/InfoQ - LinkedIn: www.linkedin.com/company/infoq - Facebook: bit.ly/2jmlyG8 - Instagram: @infoqdotcom - Youtube: www.youtube.com/infoq Write for InfoQ - Join a community of experts. - Increase your visibility. - Grow your career. www.infoq.com/write-for-infoq/?u…aign=writeforinfoq

Michael Frew is the Owner and Operator of multiple 7-figure companies and a digital business acquisitions and operations expert. He's formerly a multi million-dollar producer and managed over 200 Consulting Engagements in his career as a Software Architect and Cybersecurity Consultant with corporations including IBM, Microsoft, Amazon, Salesforce, and Mandiant. He received his B.S. and MBA in Business and Economics while studying in China, Hong Kong & The Netherlands, as well as, several post-graduate information security certifications. Having been a successful software developer and consultant for two decades, he pivoted to collaborating with other developers on small side projects to help them gain traction and grow their bootstrapped businesses. This led to a deep-dive into the niche world of digital business M&A. What started with the acquisition of a small Amazon Affiliate site, led to managing a eight-figure portfolio of e-commerce, SaaS, content, and advertising businesses a decade later. In 2023, he was selected by WebStreet to acquire and manage their inaugural SaaS/Software investment fund. Michael's business acquisition insights have been featured in dozens of media outlets like FE International, Indie Hackers, and Empire Flippers. As an author, speaker, and consultant, he is on a mission to free engineers from the disillusionment of traditional employment and educate them on how digital acquisitions can be their next career evolution. *DISCLAIMER - We are not giving any financial advice. Please DYOR* (00:00 - 03:03) Opening Segment - Michael is introduced as the guest Hosts - Michael shares something interesting about himself (03:03 - 25:07) Framework for financing and acquiring online business - Why IT professionals should stop trying to start a business and buy a business instead. - What makes developers, engineers, and other technically experienced professionals excellent online business acquirers and operators. - Why investing ni online companies outperforms other asset classes. - The answers to the top four frequently asked questions about pursuing a career in online business acquisitions. (25:07 - 28:16) Fire Round - Michael shared if she would change his investment strategy - Michael also shares his favorite Finance, real estate book, or any related book - Also Michael shared about the website and tools that he can recommend - Michael's advice to beginner investors - Also shared how he gives back (28:16 - 30:46) Closing Segment -If you want to learn more about the discussion, you can watch the podcast on⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Wealth Matter's YouTube channel ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠and you can reach out to Alpesh using this ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠link⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠. Check us out at: Facebook: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠@wealthmatrs⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠IG: @wealthmatrs.ig⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Tiktok: @wealthmatrs⁠⁠⁠⁠⁠

Our guest for the show is Ganesh Pa. Ganeshi is Founder & CEO of Uptycs, He was previously Chief Architect, Carrier Products & Strategy for Akamai Technologies, a leading provider of content delivery network services. Prior to Akamai, Ganesh was Founder & VP Systems Architecture of Verivue. Prior to Verivue, he was Principal Architect for NetDevices Whitepaper: https://www.uptycs.com/resources/white-papers/cloud-security-fundamentals Demo link: https://www.uptycs.com/request-demo About Uptycs Uptycs, the first unified CNAPP and XDR platform, reduces risk by prioritizing your responses to threats, vulnerabilities, misconfigurations, sensitive data exposure, and compliance mandates across clouds, containers, servers, and workspaces—all from a single UI and data model. Only Uptycs gives you the ability to tie together threat activity as it traverses on-prem and cloud boundaries. The result is a cloud security early warning system that identifies and stops threat actors before they can access critical data and services in the cloud. Take control of your security data, get the correlated insights you care about most, faster, and take decisive action. https://www.linkedin.com/in/ganesh-pai/ Ganesh Pai, Founder and CEO at Uptycs Ganesh Pai is Founder & CEO of Uptycs. He was previously Chief Architect, Carrier Products & Strategy for Akamai Technologies, a leading provider of content delivery network services. Prior to Akamai, Ganesh was Founder & VP Systems Architecture of Verivue. Prior to Verivue, he was Principal Architect for NetDevices. Prior to NetDevices, Ganesh served as Engineering Manager and Software Architect for Sonus Networks. He is a Boston-based entrepreneur and technologist and has been awarded multiple U.S. patents. Ganesh received a BE degree in electronics and communication engineering from Mangalore University and a MS in computer science from Temple University.

How does being a software architect differ from a typical programmer? In this episode, I share the 10 aspects I've approached software architecture from that I learned over 20 years of doing it. I was promoted to be a software architect at just 20 years old, and while I was qualified with some aspects of software engineering - I didn't really know what I was getting myself into. Being a great software architect takes a variety of skills that a typical software developer will also benefit from, but are actually essential to software architecture. Yes, using coding patterns, knowing how to interview as a software architect, and making technology selections are required. But there are also other things that if you don't focus on, can hamper your ability to pursue a software architect role either at your current job, or the next one. I hope this episode helps you understand that while there is some overlap between a software architect and a programmer, the less "fun" aspects of the job are actually essential to being a really great one. Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/ Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/ Need help with your career? Learn about career coaching:  https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks: (0:00) Introduction (0:51) 10 Aspects of Being a Software Architect (1:03) 1. Zoom In / Zoom Out (2:17) 2. Domain Sensitive (3:07) 3. Understand Tradeoffs (4:02) 4. Selfless Decision Maker (5:02) 5. Embrace Change (5:44) 6. Communicative Mastery (6:26) 7. Infrastructure Aware (7:40) 8. Strategic Coder (8:50) 9. Consider Scale (10:28) 10. Cost Sensitive (11:49) Episode Groove Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

David was the chief software architect and director of engineering at Stitch Fix. He's also the author of a number of books including Sustainable Web Development with Ruby on Rails and most recently Ruby on Rails Background Jobs with Sidekiq. He talks about how he made decisions while working with a medium sized team (~200 developers) at Stitch Fix. The audio quality for the first 19 minutes is not great but the correct microphones turn on right after that. Recorded at RubyConf 2023 in San Diego. A few topics covered: Ruby's origins at Stitch Fix Thoughts on Go Choosing technology and cloud services Moving off heroku Building a platform team Where Ruby and Rails fit in today The role of books and how different people learn Large Language Model's effects on technical content Related Links David's Blog Mastodon Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: Today. I want to share another conversation from RubyConf San Diego. This time it's with David Copeland. He was a chief software architect and director of engineering at stitch fix. And at the start of the conversation, you're going to hear about why he decided to write the book, sustainable web development with Ruby on rails. Unfortunately, you're also going to notice the sound quality isn't too good. We had some technical difficulties. But once you hit the 20 minute mark of the recording, the mics are going to kick in. It's going to sound way better. So I hope you stick with it. Enjoy. Ruby at Stitch Fix [00:00:35] David: Stitch Fix was a Rails shop. I had done a lot of Rails and learned a lot of things that worked and didn't work, at least in that situation. And so I started writing them down and I was like, I should probably make this more than just a document that I keep, you know, privately on my computer. Uh, so that's, you know, kind of, kind of where the genesis of that came from and just tried to, write everything down that I thought what worked, what didn't work. Uh, if you're in a situation like me. Working on a product, with a medium sized, uh, team, then I think the lessons in there will be useful, at least some of them. Um, and I've been trying to keep it up over, over the years. I think the first version came out a couple years ago, so I've been trying to make sure it's always up to date with the latest stuff and, and Rails and based on my experience and all that. [00:01:20] Jeremy: So it's interesting that you mention, medium sized team because, during the, the keynote, just a few moments ago, Matz the creator of Ruby was talking about how like, Oh, Rails is really suitable for this, this one person team, right? Small, small team. And, uh, he was like, you're not Google. So like, don't worry about, right. Can you scale to that level? Yeah. Um, and, and I wonder like when you talk about medium size or medium scale, like what are, what are we talking? [00:01:49] David: I think probably under 200 developers, I would say. because when I left Stitch Fix, it was closing in on that number of developers. And so it becomes, you know, hard to... You can kind of know who everybody is, or at least the names sound familiar of everybody. But beyond that, it's just, it's just really hard. But a lot of it was like, I don't have experience at like a thousand developer company. I have no idea what that's like, but I definitely know that Rails can work for like... 200 ish people how you can make it work basically. yeah. [00:02:21] Jeremy: The decision to use Rails, I'm assuming that was made before you joined? [00:02:26] David: Yeah, the, um, the CTO of Stitch Fix, he had come in to clean up a mess made by contractors, as often happens. They had used Django, which is like the Python version of Rails. And he, the CTO, he was more familiar with Rails. So the first two developers he hired, also familiar with Rails. There wasn't a lot to maintain with the Django app, so they were like, let's just start fresh, fresh with Rails. yeah, but it's funny because a lot of the code in that Rails app was, like, transliterated from Python. So you could, it would, it looked like the strangest Ruby code in the world because it was basically, there was no test. So they were like, let's just write the Ruby version of this Python just so we know it works. but obviously that didn't, didn't last forever, so. [00:03:07] Jeremy: So, so what's an example of a, of a tell? Where you're looking at the code and you're like, oh, this is clearly, it came from Python. [00:03:15] David: You'd see like, very, very explicit, right? Like Python, there's a lot of like single line things. very like, this sounds like a dig, but it's very simple looking code. Like, like I don't know Python, but I was able to change this Django app. And I had to, I could look at it and you can figure out immediately how it works. Cause there's. Not much to it. There's nothing fancy. So, like, this, this Ruby code, there was nothing fancy. You'd be like, well, maybe they should have memoized that, or maybe they should have taken that into another class, or you could have done this with a hash or something like that. So there was, like, none of that. It was just, like, really basic, plain code like you would see in any beginning programming language kind of thing. Which is at least nice. You can understand it. but you probably wouldn't have written it that way at first in Ruby. Thoughts on Go [00:04:05] Jeremy: Yeah, that's, that's interesting because, uh, people sometimes talk about the Go programming language and how it looks, I don't know if simple is the right word, but it's something where you look at the code and even if you don't necessarily understand Go, it's relatively straightforward. Yeah. I wonder what your thoughts are on that being a strength versus that being, like, [00:04:25] David: Yeah, so at Stitch Fix at one point we had a pro, we were moving off of Heroku and we were going to, basically build a deployment platform using ECS on AWS. And so the deployment platform was a Rails app and we built a command line tool using Ruby. And it was fine, but it was a very complicated command line tool and it was very slow. And so one of the developers was like, I'm going to rewrite it in Go. I was like, ugh, you know, because I just was not a big fan. So he rewrote it in Go. It was a bazillion times faster. And then I was like, okay, I'm going to add, I'll add a feature to it. It was extremely easy. Like, it's just like what you said. I looked at it, like, I don't know anything about Go. I know what is happening here. I can copy and paste this and change things and make it work for what I want to do. And it did work. And it was, it was pretty easy. so there's that, I mean, aesthetically it's pretty ugly and it's, I, I. I can't really defend that as a real reason to not use it, but it is kind of gross. I did do Go, I did a small project in Go after Stitch Fix, and there's this vibe in Go about like, don't create abstractions. I don't know where I got that from, but every Go I look at, I'm like we should make an abstraction for this, but it's just not the vibe. They just don't like doing that. They like it all written out. And I see the value because you can look at the code and know what it does and you don't have to chase abstractions anywhere. But. I felt like I was copying and pasting a lot of, a lot of things. Um, so I don't know. I mean, the, the team at Stitch Fix that did this like command line app in go, they're the platform team. And so their job isn't to write like web apps all day, every day. There's kind of in and out of all kinds of things. They have to try to figure out something that they don't understand quickly to debug a problem. And so I can see the value of something like go if that's your job, right? You want to go in and see what the issue is. Figure it out and be done and you're not going to necessarily develop deep expertise and whatever that thing is that you're kind of jumping into. Day to day though, I don't know. I think it would make me kind of sad. (laughs) [00:06:18] Jeremy: So, so when you say it would make you kind of sad, I mean, what, what about it? Is it, I mean, you mentioned that there's a lot of copy and pasting, so maybe there's code duplication, but are there specific things where you're like, oh, I just don't? [00:06:31] David: Yeah, so I had done a lot of Java in my past life and it felt very much like that. Where like, like the Go library for making an HTTP call for like, I want to call some web service. It's got every feature you could ever want. Everything is tweakable. You can really, you can see why it's designed that way. To dial in some performance issue or solve some really esoteric thing. It's there. But the problem is if you just want to get an JSON, it's just like huge production. And I felt like that's all I really want to do and it's just not making it very easy. And it just felt very, very cumbersome. I think that having to declare types also is a little bit of a weird mindset because, I mean, I like to make types in Ruby, I like to make classes, but I also like to just use hashes and stuff to figure it out. And then maybe I'll make a class if I figure it out, but Go, you can't. You have to have a class, you have to have a type, you have to think all that ahead of time, and it just, I'm not used to working that way, so it felt, I mean, I guess I could get used to it, but I just didn't warm up to that sort of style of working, so it just felt like I was just kind of fighting with the vibe of the language, kind of. Yeah, [00:07:40] Jeremy: so it's more of the vibe or the feel where you're writing it and you're like this seems a little too... Explicit. I feel like I have to be too verbose. It just doesn't feel natural for me to write this. [00:07:53] David: Right, it's not optimized for what in my mind is the obvious case. And maybe that's not the obvious case for the people that write Go programs. But for me, like, I just want to like get this endpoint and get the JSON back as a map. Not any easier than any other case, right? Whereas like in Ruby, right? And you can, I think if you include net HTTP, you can just type get. And it will just return whatever that is. Like, that's amazing. It's optimized for what I think is a very common use case. So it makes me feel really productive. It makes me feel pretty good. And if that doesn't work out long term, I can always use something more complicated. But I'm not required to dig into the NetHttp library just to do what in my mind is something very simple. [00:08:37] Jeremy: Yeah, I think that's something I've noticed myself in working with Ruby. I mean, you have the standard library that's very... Comprehensive and the API surface is such that, like you said there, when you're trying to do common tasks, a lot of times they have a call you make and it kind of does the thing you expected or hoped for. [00:08:56] David: Yeah, yeah. It's kind of, I mean, it's that whole optimized for programmer happiness thing. Like it does. That is the vibe of Ruby and it seems like that is still the way things are. And, you know, I, I suppose if I had a different mindset, I mean, because I work with developers who did not like using Ruby or Rails. They loved using Go or Java. And I, I guess there's probably some psychological analysis we could do about their background and history and mindset that makes that make sense. But, to me, I don't know. It's, it's nice when it's pleasant. And Ruby seems pleasant. (laughs) Choosing Technology [00:09:27] Jeremy: as a... Software Architect, or as a CTO, when, when you're choosing technology, what are some of the things you look at in terms of, you know? [00:09:38] David: Yeah, I mean, I think, like, it's a weird criteria, but I think what is something that the team is capable of executing with? Because, like, most, right, most programming languages all kind of do the same thing. Like, you can kind of get most stuff done in most common popular programming languages. So, it's probably not... It's not true that if you pick the wrong language, you can't build the app. Like, that's probably not really the case. At least for like a web app or something. so it's more like, what is the team that's here to do it? What are they comfortable and capable of doing? I worked on a project with... It was a mix of like junior engineers who knew JavaScript, and then some senior engineers from Google. And for whatever reason someone had chosen a Rails app and none of them were comfortable or really yet competent with doing Ruby on Rails and they just all hated it and like it didn't work very well. Um, and so even though, yes, Rails is a good choice for doing stuff for that team at that moment. Not a good choice. Right. So I think you have to go in and like, what, what are we going to be able to execute on so that when the business wants us to do something, we just do it. And we don't complain and we don't say, Oh, well we can't because this technology that we chose, blah, blah, blah. Like you don't ever want to say that if possible. So I think that's. That's kind of the, the top thing. I think second would be how widely supported is it? Like you don't want to be the cutting edge user that's finding all the bugs in something really. Like you want to use something that's stable. Postgres, MySQL, like those work, those are fine. The bugs have been sorted out for most common use cases. Some super fancy edge database, I don't know if I'd want to be doing, doing that you know? Choosing cloud services [00:11:15] Jeremy: How do you feel about the cloud specific services and databases? Like are you comfortable saying like, oh, I'm going to use... Google Cloud, BigQuery. Yeah. [00:11:27] David: That sort of thing. I think it would kind of fall under the same criteria that I was just, just saying like, so with AWS it's interesting 'cause when we moved from Heroku to AWS by EC2 RDS, their database thing, uh, S3, those have been around for years, probably those are gonna work, but they always introduce new things. Like we, we use RabbitMQ and AWS came out with. Some, I forget what it was, it was a queuing service similar to Rabbit. We were like, Oh, maybe we should switch to that. But it was clear that they weren't really ready to support it. So. Yeah, so we didn't, we didn't switch to that. So I, you gotta try to read the tea leaves of the provider to see are they committed to, to supporting this thing or is this there to get some enterprise client to move into the cloud. And then the idea is to move off of that transitional thing into what they do support. And it's hard to get a clear answer from them too. So it takes a little bit of research to figure out, Are they going to support this or not? Because that's what you don't want. To move everything into some very proprietary cloud system and have them sunset it and say, Oh yeah, now you've got to switch again. Uh, that kind of sucks. So, it's a little trickier. [00:12:41] Jeremy: And what kind of questions or research do you do? Is it purely a function of this thing has existed for X number of years so I feel okay? [00:12:52] David: I mean, it's kind of similar to looking at like some gem you're going to add to your project, right? So you'll, you'll look at how often does it change? Is it being updated? Uh, what is the documentation? Does it look like someone really cared about the documentation? Does the documentation look updated? Are there issues with it that are being addressed or, or not? Um, so those are good signals. I think, talking to other practitioners too can be good. Like if you've got someone who's experienced. You can say, hey, do you know anybody back channeling through, like, everybody knows somebody that works at AWS, you can probably try to get something there. at Stitch Fix, we had an enterprise support contract, and so your account manager will sometimes give you good information if you ask. Again, it's a, they're not going to come out and say, don't use this product that we have, but they might communicate that in a subtle way. So you have to triangulate from all these sources to try to. to try to figure out what, what you want to do. [00:13:50] Jeremy: Yeah, it kind of makes me wish that there was a, a site like, maybe not quite like, can I use, right? Can I use, you can see like, oh, can I use this in my browser? Is there, uh, like an AWS or a Google Cloud? Can I trust this? Can I trust this? Yeah. Is this, is this solid or not? [00:14:04] David: Right, totally. It's like, there's that, that site where you, it has all the Apple products and it says whether or not you should buy it because one may or may not be coming out or they may be getting rid of it. Like, yeah, that would... For cloud services, that would be, that would be nice. [00:14:16] Jeremy: Yeah, yeah. That's like the Mac Buyer's Guide. And then we, we need the, uh, the technology. Yeah. Maybe not buyers. Cloud Provider Buyer's Guide, yeah. I guess we are buyers. [00:14:25] David: Yeah, yeah, totally, totally. [00:14:27] Jeremy: it's interesting that you, you mentioned how you want to see that, okay, this thing is mature. I think it's going to stick around because, I, interviewed, someone who worked on, I believe it was the CloudWatch team. Okay. Daniel Vassalo, yeah. so he left AWS, uh, after I think about 10 years, and then he wrote a book called, uh, The Good Parts of AWS. Oh! And, if you read his book, most of the services he says to use are the ones that are, like, old. Yeah. He's, he's basically saying, like, S3, you know you're good. Yeah. Right? but then all these, if you look at the AWS webpage, they have who knows, I don't know how many hundreds of services. Yeah. He's, he's kind of like I worked there and I would not use, you know, all these new services. 'cause I myself, I don't trust [00:15:14] David: it yet. Right. And so, and they're working there? Yeah, they're working there. Yeah. No. One of the VPs at Stitch Fix had worked on Google Cloud and so when we were doing this transition from Heroku, he was like, we are not using Google Cloud. I was like, really? He's like AWS is far ahead of the game. Do not use Google Cloud. I was like, all right, I don't need any more info. You work there. You said don't. I'm gonna believe you. So [00:15:36] Jeremy: what, what was his did he have like a core point? [00:15:39] David: Um, so he never really had anything bad to say about Google per se. Like I think he enjoyed his time there and I think he thought highly of who he worked with and what he worked on and that sort of thing. But his, where he was coming from was like AWS was so far ahead. of Google on anything that we would use, he was like, there's, there's really no advantage to, to doing it. AWS is a known quantity, right? it's probably still the case. It's like, you know, you've heard the nobody ever got fired for using IBM or using Microsoft or whatever the thing is. Like, I think that's, that was kind of the vibe. And he was like, moving all of our infrastructure right before we're going to go public. This is a serious business. We should just use something that we know will work. And he was like, I know this will work. I'm not confident about. Google, uh, for our use case. So we shouldn't, we shouldn't risk it. So I was like, okay, I trust you because I didn't know anything about any of that stuff at the time. I knew Heroku and that was it. So, yeah. [00:16:34] Jeremy: I don't know if it's good or bad, but like you said, AWS seems to be the default choice. Yeah. And I mean, there's people who use Azure. I assume it's mostly primarily Microsoft. Yeah. And then there's Google Cloud. It's not really clear why you would pick it, unless there was a specific service or something that only they had. [00:16:55] David: Yeah, yeah. Or you're invested in Google, you know, you want to keep everything there. I mean, I don't know. I haven't really been at that level to make that kind of decision, and I would probably choose AWS for the reasons discussed, but, yeah. Moving off Heroku [00:17:10] Jeremy: And then, so at Stitch Fix, you said you moved off of Heroku [00:17:16] David: yeah. Yeah, so we were heavy into Heroku. I think that we were told that at one point we had the biggest Heroku Postgres database on their platform. Not a good place to be, right? You never want to be the biggest customer person, usually. but the problem we were facing was essentially we were going to go public. And to do that, you're under all the scrutiny. about many things, including the IT systems and the security around there. So, like, by default, a Postgres, a Heroku Postgres database is, like, on the internet. It's only secured by the password. all their services are on the internet. So, not, not ideal. they were developing their private cloud service at that time. And so that would have given us, in theory, on paper, it would have solved all of our problems. And we liked Heroku and we liked the developer experience. It was great. but... Heroku private spaces, it was still early. There's a lot of limitations that when they explained why those limitations, they were reasonable. And if we had. started from scratch on Heroku Private Spaces. It probably would have worked great, but we hadn't. So we just couldn't make it work. So we were like, okay, we're going to have to move to AWS so that everything can be basically off the internet. Like our public website needs to be on the internet and that's kind of it. So we need to, so that's basically was the, was the impetus for that. but it's too bad because I love Heroku. It was great. I mean, they were, they were a great partner. They were great. I think if Stitch Fix had started life a year later, Private Spaces. Now it's, it's, it's way different than it was then. Cause it's been, it's a mature product now, so we could have easily done that, but you know, the timing didn't work out, unfortunately. [00:18:50] Jeremy: And that was a compliance thing to, [00:18:53] David: Yeah. And compliance is weird cause they don't tell you what to do, but they give you some parameters that you need to meet. And so one of them is like how you control access. So, so going public, the compliance is around the financial data and. Ensuring that the financial data is accurate. So a lot of the systems at Stichfix were storing the financial data. We, you know, the warehouse management system was custom made. Uh, all the credit card processing was all done, like it was all in some databases that we had running in Heroku. And so those needed to be subject to stricter security than we could achieve with just a single password that we just had to remember to rotate when someone like left the team. So that was, you know, the kind of, the kind of impetus for, for all of that. [00:19:35] Jeremy: when you were using Heroku, Salesforce would have already owned it then. Did you, did you get any sense that you weren't really sure about the future of the platform while you're on it or, [00:19:45] David: At that time, no, it seemed like they were still innovating. So like, Heroku has a Redis product now. They didn't at the time we wish that they did. They told us they're working on it, but it wasn't ready. We didn't like using the third parties. Kafka was not a thing. We very much were interested in that. We would have totally used it if it was there. So they were still. Like doing bigger innovations then, then it seems like they are now. I don't know. It's weird. Like they're still there. They still make money, I assume for Salesforce. So it doesn't feel like they're going away, but they're not innovating at the pace that they were kind of back in the day. [00:20:20] Jeremy: it used to feel like when somebody's asking, I want to host a Rails app. Then you would say like, well, use Heroku because it's basically the easiest to get started. It's a known quantity and it's, it's expensive, but, it seemed for, for most people, it was worth it. and then now if I talk to people, it's like. Not what people suggest anymore. [00:20:40] David: Yeah, because there's, there's actual competitors. It's crazy to me that there was no competitors for years, and now there's like, Render and Fly. io seem to be the two popular alternatives. Um, I doubt they're any cheaper, honestly, but... You get a sense, right, that they're still innovating, still building those platforms, and they can build with, you know, all of the knowledge of what has come before them, and do things differently that might, that might help. So, I still use Heroku for personal things just because I know it, and I, you know, sometimes you don't feel like learning a new thing when you just want to get something done, but, yeah, I, I don't know if we were starting again, I don't know, maybe I'd look into those things. They, they seem like they're getting pretty mature and. Heroku's resting on its laurels, still. [00:21:26] Jeremy: I guess I never quite the mindset, right? Where you You have a platform that's doing really well and people really like it and you acquire it and then it just It seems like you would want to keep it rolling, right? (laughs) [00:21:38] David: Yeah, it's, it is wild, I mean, I guess... Why did you, what was Salesforce thinking they were going to get? Uh, who knows maybe the person at Salesforce that really wanted to purchase it isn't there. And so no one at Salesforce cares about it. I mean, there's all these weird company politics that like, who knows what's going on and you could speculate. all day. What's interesting is like, there's definitely some people in the Ruby community who work there and still are working there. And that's like a little bit of a canary for me. I'm like, all right, well, if that person's still working there, that person seems like they're on the level and, and, and, and seems pretty good. They're still working there. It, it's gotta be still a cool place to be or still doing something, something good. But, yeah, I don't know. I would, I would love to know what was going on in all the Salesforce meetings about acquiring that, how to manage it. What are their plans for it? I would love to know that stuff. [00:22:29] Jeremy: maybe you had some experience with this at Stitch Fix But I've heard with Heroku some of their support staff at least in the past they would, to some extent, actually help you troubleshoot, like, what's going on with your app. Like, if your app is, like, using a whole bunch of memory, and you're out of memory, um, they would actually kind of look into that, for you, which is interesting, because it's like, that's almost like a services thing than it is just a platform. [00:22:50] David: Yeah. I mean, they, their support, you would get, you would get escalated to like an engineer sometimes, like who worked on that stuff and they would help figure out what the problem was. Like you got the sense that everybody there really wanted the platform to be good and that they were all sort of motivated to make sure that everybody. You know, did well and used the platform. And they also were good at, like a thing that trips everybody up about Heroku is that your app restarts every day. And if you don't know anything about anything, you might think that is stupid. Why, why would I want that? That's annoying. And I definitely went through that and I complained to them a lot. And I'm like, if you only could not restart. And they very patiently and politely explained to me why that it needed to do that, they weren't going to remove that, and how to think about my app given that reality, right? Which is great because like, what company does that, right? From the engineers that are working on it, like No, nobody does that. So, yeah, no, I haven't escalated anything to support at Heroku in quite some time, so I don't know if it's still like that. I hope it is, but I'm not really, not really sure. Building a platform team [00:23:55] Jeremy: Yeah, that, uh, that reminds me a little bit of, I think it's Rackspace? There's, there's, like, another hosting provider that was pretty popular before, and they... Used to be famous for that type of support, where like your, your app's having issues and somebody's actually, uh, SSHing into your box and trying to figure out like, okay, what's going on? which if, if that's happening, then I, I can totally see where the, the price is justified. But if the support is kind of like dropping off to where it's just, they don't do that kind of thing, then yeah, I can see why it's not so much of a, yeah, [00:24:27] David: We used to think of Heroku as like they were the platform team before we had our own platform team and they, they acted like it, which was great. [00:24:35] Jeremy: Yeah, I don't have, um, experience with, render, but I, I, I did, talk to someone from there, and it does seem like they're, they're trying to fill that role, um, so, yeah, hopefully, they and, and other companies, I guess like Vercel and things like that, um, they're, they're all trying to fill that space, [00:24:55] David: Yeah, cause, cause building our own internal platform, I mean it was the right thing to do, but it's, it's a, you can't just, you have to have a team on it, it's complicated, getting all the stuff in AWS to work the way you want it to work, to have it be kind of like Heroku, like it's not trivial. if I'm a one person company, I don't want to be messing around with that particularly. I want to just have it, you know, push it up and have it go and I'm willing to pay for that. So it seems logical that there would be competitors in that space. I'm glad there are. Hopefully that'll light a fire under, under everybody. [00:25:26] Jeremy: so in your case, it sounds like you moved to having your own platform team and stuff like that, uh, partly because of the compliance thing where you're like, we need our, we need to be isolated from the internet. We're going to go to AWS. If you didn't have that requirement, do you still think like that would have been the time to, to have your own platform team and manage that all yourself? [00:25:46] David: I don't know. We, we were thinking an issue that we were running into when we got bigger, um, was that, I mean, Heroku, it, It's obviously not as flexible as AWS, but it is still very flexible. And so we had a lot of internal documentation about this is how you use Heroku to do X, Y, and Z. This is how you set up a Stitch Fix app for Heroku. Like there was just the way that we wanted it to be used to sort of. Just make it all manageable. And so we were considering having a team spun up to sort of add some tooling around that to sort of make that a little bit easier for everybody. So I think there may have been something around there. I don't know if it would have been called a platform team. Maybe we call, we thought about calling it like developer happiness or because you got developer experience or something. We, we probably would have had something there, but. I do wonder how easy it would have been to fund that team with developers if we hadn't had these sort of business constraints around there. yeah, um, I don't know. You get to a certain size, you need some kind of manageability and consistency no matter what you're using underneath. So you've got to have, somebody has to own it to make sure that it's, that it's happening. [00:26:50] Jeremy: So even at your, your architect level, you still think it would have been a challenge to, to. Come to the executive team and go like, I need funding to build this team. [00:27:00] David: You know, certainly it's a challenge because everybody, you know, right? Nobody wants to put developers in anything, right? There are, there are a commodity and I mean, that is kind of the job of like, you know, the staff engineer or the architect at a company is you don't have, you don't have the power to put anybody on anything you, you have the power to Schedule a meeting with a VP or the CTO and they will listen to you. And that's basically, you've got to use that power to convince them of what you want done. And they're all reasonable people, but they're balancing 20 other priorities. So it would, I would have had to, it would have been a harder case to make that, Hey, I want to take three engineers. And have them write tooling to make Heroku easier to use. What? Heroku is not easy to use. Why aren't, you know, so you really, I would, it would be a little bit more of a stretch to walk them through it. I think a case could be made, but, definitely would take some more, more convincing than, than what was needed in our case. [00:27:53] Jeremy: Yeah. And I guess if you're able to contrast that with, you were saying, Oh, I need three people to help me make Heroku easier. Your actual platform team on AWS, I imagine was much larger, right? [00:28:03] David: Initially it was, there was, it was three people did the initial move over. And so by the time we went public, we'd been on this new system for, I don't know, six to nine months. I can't remember exactly. And so at that time the platform team was four or five people, and I, I mean, so percentage wise, right, the engineering team was maybe almost 200, 150, 200. So percentage wise, maybe a little small, I don't know. but it kind of gets back to the power of like the rails and the one person framework. Like everything we did was very much the same And so the Rails app that managed the deployment was very simple. The, the command line app, even the Go one with all of its verbosity was very, very simple. so it was pretty easy for that small team to manage. but, Yeah, so it was sort of like for redundancy, we probably needed more than three or four people because you know, somebody goes out sick or takes a vacation. That's a significant part of the team. But in terms of like just managing the complexity and building it and maintaining it, like it worked pretty well with, you know, four or five people. Where Rails fits in vs other technology [00:29:09] Jeremy: So during the Keynote today, they were talking about how companies like GitHub and Shopify and so on, they're, they're using Rails and they're, they're successful and they're fairly large. but I think the thing that was sort of unsaid was the fact that. These companies, while they use Rails, they use a lot of other, technology as well. And, and, and kind of increasing amounts as well. So, I wonder from your perspective, either from your experience at StitchFix or maybe going forward, what is the role that, that Ruby and Rails plays? Like, where does it make sense for that to be used versus like, Okay, we need to go and build something in Java or, you know, or Go, that sort of thing? [00:29:51] David: right. I mean, I think for like your standard database backed web app, it's obviously great. especially if your sort of mindset bought into server side rendering, it's going to be great at that. so like internal tools, like the customer service dashboard or... You know, something for like somebody who works at a company to use. Like, it's really great because you can go super fast. You're not going to be under a lot of performance constraints. So you kind of don't even have to think about it. Don't even have to solve it. You can, but you don't have to, where it wouldn't work, I guess, you know, if you have really strict performance. Requirements, you know, like a, a Go version of some API server is going to use like percentages of what, of what Rails would use. If that's meaningful, if what you're spending on memory or compute is, is meaningful, then, then yeah. That, that becomes worthy of consideration. I guess if you're, you know, if you're making a mobile app, you probably need to make a mobile app and use those platforms. I mean, I guess you can wrap a Rails app sort of, but you're still making, you still need to make a mobile app, that does something. yeah. And then, you know, interestingly, the data science part of Stitch Fix was not part of the engineering team. They were kind of a separate org. I think Ruby and Rails was probably the only thing they didn't use over there. Like all the ML stuff, everything is either Java or Scala or Python. They use all that stuff. And so, yeah, if you want to do AI and ML with Ruby, you, it's, it's hard cause there's just not a lot there. You really probably should use Python. It'll make your life easier. so yeah, those would be some of the considerations, I guess. [00:31:31] Jeremy: Yeah, so I guess in the case of, ML, Python, certainly, just because of the, the ecosystem, for maybe making a command line application, maybe Go, um, Go or Rust, perhaps, [00:31:44] David: Right. Cause you just get a single binary. Like the problem, I mean, I wrote this book on Ruby command line apps and the biggest problem is like, how do I get the Ruby VM to be anywhere so that it can then run my like awesome scripts? Like that's kind of a huge pain. (laughs) So [00:31:59] Jeremy: and then you said, like, if it's Very performance sensitive, which I am kind of curious in, in your experience with the companies you've worked at, when you're taking on a project like that, do you know up front where you're like, Oh, the CPU and memory usage is going to be a problem, or is it's like you build it and you're like, Oh, this isn't working. So now I know. [00:32:18] David: yeah, I mean, I, I don't have a ton of great experience there at Stitch Fix. The biggest expense the company had was the inventory. So like the, the cost of AWS was just de minimis compared to all that. So nobody ever came and said, Hey, you've got to like really save costs on, on that stuff. Cause it just didn't really matter. at the, the mental health startup I was at, it was too early. But again, the labor costs were just far, far exceeded the amount of money I was spending on, on, um, you know, compute and infrastructure and stuff like that. So, Not knowing anything, I would probably just sort of wait and see if it's a problem. But I suppose you always take into account, like, what am I actually building? And like, what does this business have to scale to, to make it worthwhile? And therefore you can kind of do a little bit of planning ahead there. But, I dunno, I think it would kind of have to depend. [00:33:07] Jeremy: There's a sort of, I guess you could call it a meme, where people say like, Oh, it's, it's not, it's not Rails that's slow, it's the, the database that's slow. And, uh, I wonder, is that, is that accurate in your experience, or, [00:33:20] David: I mean, most of the stuff that we had that was slow was the database, because like, it's really easy to write a crappy query in Rails if you're not, if you're not careful, and then it's really easy to design a database that doesn't have any indexes if you're not careful. Like, you, you kind of need to know that, But of course, those are easy to fix too, because you just add the index, especially if it's before the database gets too big where we're adding indexes is problematic. But, I think those are just easy performance mistakes to make. Uh, especially with Rails because you're not, I mean, a lot of the Rails developers at Citrix did not know SQL at all. I mean, they had to learn it eventually, but they didn't know it at all. So they're not even knowing that what they're writing could possibly be problematic. It's just, you're writing it the Rails way and it just kind of works. And at a small scale, it does. And it doesn't matter until, until one day it does. [00:34:06] Jeremy: And then in, in the context of, let's say, using ActiveRecord and instantiating the objects, or, uh, the time it takes to render templates, that kinds of things, to, at least in your experience, that wasn't such of an issue. [00:34:20] David: No, and it was always, I mean, whenever we looked at why something was slow, it was always the database and like, you know, you're iterating over some active records and then, and then, you know, you're going into there and you're just following this object graph. I've got a lot of the, a lot of the software at Stitch Fix was like internal stuff and it was visualizing complicated data out of the database. And so if you didn't think about it, you would just start dereferencing and following those relationships and you have this just massive view and like the HTML is fine. It's just that to render this div, you're. Digging into some active record super deep. and so, you know, that was usually the, the, the problems that we would see and they're usually easy enough to fix by making an index or. Sometimes you do some caching or something like that. and that solved most of the, most of the issues [00:35:09] Jeremy: The different ways people learn [00:35:09] Jeremy: so you're also the author of the book, Sustainable Web Development with Ruby on Rails. And when you talk to people about like how they learn things, a lot of them are going on YouTube, they're going on, uh, you know, looking for blogs and things like that. And so as an author, what do you think the role is of, of books now? Yeah, [00:35:29] David: I have thought about this a lot, because I, when I first got started, I'm pretty old, so books were all you had, really. Um, so they seem very normal and natural to me, but... does someone want to sit down and read a 400 page technical book? I don't know. so Dave Thomas who runs Pragmatic Bookshelf, he was on a podcast and was asked the same question and basically his answer, which is my answer, is like a long form book is where you can really lay out your thinking, really clarify what you mean, really take the time to develop sometimes nuanced, examples or nuanced takes on something that are Pretty hard to do in a short form video or in a blog post. Because the expectation is, you know, someone sends you an hour long YouTube video, you're probably not going to watch that. Two minute YouTube video is sure, but you can't, you can't get into so much, kind of nuanced detail. And so I thought that was, was right. And that was kind of my motivation for writing. I've got some thoughts. They're too detailed. It's, it's too much set up for a blog post. There's too much of a nuanced element to like, really get across. So I need to like, write more. And that means that someone's going to have to read more to kind of get to it. But hopefully it'll be, it'll be valuable. one of the sessions that we're doing later today is Ruby content creators, where it's going to be me and Noel Rappin and Dave Thomas representing the old school dudes that write books and probably a bunch of other people that do, you know, podcasts videos. It'd be interesting to see, I really want to know how do people learn stuff? Because if no one reads books to learn things, then there's not a lot of point in doing it. But if there is value, then, you know. It should be good and should be accessible to people. So, that's why I do it. But I definitely recognize maybe I'm too old and, uh, I'm not hip with the kids or, or whatever, whatever the case is. I don't know. [00:37:20] Jeremy: it's tricky because, I think it depends on where you are in the process of learning that thing. Because, let's say, you know a fair amount about the technology already. And you look at a book, in a lot of cases it's, it's sort of like taking you from nothing to something. And so you're like, well, maybe half of this isn't relevant to me, but then if I don't read it, then I'm probably missing a lot still. And so you're in this weird in be in between zone. Another thing is that a lot of times when people are trying to learn something, they have a specific problem. And, um, I guess with, with books, it's, you kind of don't know for sure if the thing you're looking for is going to be in the book. [00:38:13] David: I mean, so my, so my book, I would not say as a beginner, it's not a book to learn how to do Rails. It's like you already kind of know Rails and you want to like learn some comprehensive practices. That's what my book is for. And so sometimes people will ask me, I don't know Rails, should I get your book? And I'm like, no, you should not. but then you have the opposite thing where like the agile web development with Rails is like the beginner version. And some people are like, Oh, it's being updated for Rails 7. Should I get it? I'm like, probably not because How to go from zero to rails hasn't changed a lot in years. There's not that much that's going to be new. but, how do you know that, right? Hopefully the Table of Contents tells you. I mean, the first book I wrote with Pragmatic, they basically were like, The Table of Contents is the only thing the reader, potential reader is going to have to have any idea what's in the book. So, You need to write the table of contents with that in mind, which may not be how you'd write the subsections of a book, but since you know that it's going to serve these dual purposes of organizing the book, but also being promotional material that people can read, you've got to keep that in mind, because otherwise, how does anybody, like you said, how does anybody know what's, what's going to be in there? And they're not cheap, I mean, these books are 50 bucks sometimes, and That's a lot of money for people in the U. S. People outside the U. S. That's a ton of money. So you want to make sure that they know what they're getting and don't feel ripped off. [00:39:33] Jeremy: Yeah, I think the other challenge is, at least what I've heard, is that... When people see a video course, for whatever reason, they, they set, like, a higher value to it. They go, like, oh, this video course is, 200 dollars and it's, like, seems like a lot of money, but for some people it's, like, okay, I can do that. But then if you say, like, oh, this, this book I've been researching for five years, uh, I want to sell it for a hundred bucks, people are going to be, like no. No way., [00:40:00] David: Yeah. Right. A hundred bucks for a book. There's no way. That's a, that's a lot. Yeah. I mean, producing video, I've thought about doing video content, but it seems so labor intensive. Um, and it's kind of like, It's sort of like a performance. Like I was mentioning before we started that I used to play in bands and like, there's a lot to go into making an even mediocre performance. And so I feel like, you know, video content is the same way. So I get that it like, it does cost more to produce, but, are you getting more information out of it? I, that, I don't know, like maybe not, but who knows? I mean, people learn things in different ways. So, [00:40:35] Jeremy: It's just like this perception thing, I think. And, uh, I'm not sure why that is. Um, [00:40:40] David: Yeah, maybe it's newer, right? Maybe books feel older so they're easier to make and video seems newer. I mean, I don't know. I would love to talk to engineers who are like... young out of college, a few years into their career to see what their perception of this stuff is. Cause I mean, there was no, I mean, like I said, I read books cause that's all there was. There was no, no videos. You, you go to a conference and you read a book and that was, that was all you had. so I get it. It seems a whole video. It's fancier. It's newer. yeah, I don't know. I would love to hear a wide variety of takes on it to see what's actually the, the future, you know? [00:41:15] Jeremy: sure, yeah. I mean, I think it probably can't just be one or the other, right? Like, I think there are... Benefits of each way. Like, if you have the book, you can read it at your own pace without having to, like, scroll through the video, and you can easily copy and paste the, the code segments, [00:41:35] David: Search it. Go back and forth. [00:41:36] Jeremy: yeah, search it. So, I think there's a place for it, but yeah, I think it would be very interesting, like you said, to, to see, like, how are people learning, [00:41:45] David: Right. Right. Yeah. Well, it's the same with blogs and podcasts. Like I, a lot of podcasters I think used to be bloggers and they realized that like they can get out what they need by doing a podcast. And it's way easier because it's more conversational. You don't have to do a bunch of research. You don't have to do a bunch of editing. As long as you're semi coherent, you can just have a conversation with somebody and sort of get at some sort of thing that you want to talk about or have an opinion about. And. So you, you, you see a lot more podcasts and a lot less blogs out there because of that. So it's, that's kind of like the creators I think are kind of driving that a little bit. yeah. So I don't know. [00:42:22] Jeremy: Yeah, I mean, I can, I can say for myself, the thing about podcasts is that it's something that I can listen to while I'm doing something else. And so you sort of passively can hopefully pick something up out of that conversation, but... Like, I think it's maybe not so good at the details, right? Like, if you're talking code, you can talk about it over voice, but can you really visualize it? Yeah, yeah, yeah. I think if you sit down and you try to implement something somebody talked about, you're gonna be like, I don't know what's happening. [00:42:51] David: Yeah. [00:42:52] Jeremy: So, uh, so, so I think there's like these, these different roles I think almost for so like maybe you know the podcast is for you to Maybe get some ideas or get some familiarity with a thing and then when you're ready to go deeper You can go look at a blog post or read a book I think video kind of straddles those two where sometimes video is good if you want to just see, the general concept of a thing, and have somebody explain it to you, maybe do some visuals. that's really good. but then it can also be kind of detailed, where, especially like the people who stream their process, right, you can see them, Oh, let's, let's build this thing together. You can ask me questions, you can see how I think. I think that can be really powerful. at the same time, like you said, it can be hard to say, like, you know, I look at some of the streams and it's like, oh, this is a three hour stream and like, well, I mean, I'm interested. I'm interested, but yeah, it's hard enough for me to sit through a, uh, a three hour movie, [00:43:52] David: Well, then that, and that gets into like, I mean, we're, you know, we're at a conference and they, they're doing something a little, like, there are conference talks at this conference, but there's also like. sort of less defined activities that aren't a conference talk. And I think that could be a reaction to some of this too. It's like I could watch a conference talk on, on video. How different is that going to be than being there in person? maybe it's not that different. Maybe, maybe I don't need to like travel across the country to go. Do something that I could see on video. So there's gotta be something here that, that, that meets that need that I can't meet any other way. So it's all these different, like, I would like to think that's how it is, right? All this media all is a part to play and it's all going to kind of continue and thrive and it's not going to be like, Oh, remember books? Like maybe, but hopefully not. Hopefully it's like, like what you're saying. Like it's all kind of serving different purposes that all kind of work together. Yeah. [00:44:43] Jeremy: I hope that's the case, because, um, I don't want to have to scroll through too many videos. [00:44:48] David: Yeah. The video's not for me. Large Language Models [00:44:50] Jeremy: I, I like, I actually do find it helpful, like, like I said, for the high level thing, or just to see someone's thought process, but it's like, if you want to know a thing, and you have a short amount of time, maybe not the best, um, of course, now you have all the large language model stuff where you like, you feed the video in like, Hey, tell, tell, tell me, uh, what this video is about and give me the code snippets and all that stuff. I don't know how well it works, but it seems [00:45:14] David: It's gotta get better. Cause you go to a support site and they're like, here's how to fix your problem, and it's a video. And I'm like, can you just tell me? But I'd never thought about asking the AI to just look at the video and tell me. So yeah, it's not bad. [00:45:25] Jeremy: I think, that's probably where we're going. So it's, uh, it's a little weird to think about, but, [00:45:29] David: yeah, yeah. I was just updating, uh, you know, like I said, I try to keep the book updated when new versions of Rails come out, so I'm getting ready to update it for Rails 7. 1 and in Amazon's, Kindle Direct Publishing as their sort of backend for where you, you know, publish like a Kindle book and stuff, and so they added a new question, was AI used in the production of this thing or not? And if you answer yes, they want you to say how much, And I don't know what they're gonna do with that exactly, but I thought it was pretty interesting, cause I would be very disappointed to pay 50 for a book that the AI wrote, right? So it's good that they're asking that? Yeah. [00:46:02] Jeremy: I think the problem Amazon is facing is where people wholesale have the AI write the book, and the person either doesn't review it at all, or maybe looks at a little, a little bit. And, I mean, the, the large language model stuff is very impressive, but If you have it generate a technical book for you, it's not going to be good. [00:46:22] David: yeah. And I guess, cause cause like Amazon, I mean, think about like Amazon scale, like they're not looking at the book at all. Like I, I can go click a button and have my book available and no person's going to look at it. they might scan it or something maybe with looking for bad words. I don't know, but there's no curation process there. So I could, yeah. I could see where they could have that, that kind of problem. And like you as the, as the buyer, you don't necessarily, if you want to book on something really esoteric, there are a lot of topics I wish there was a book on that there isn't. And as someone generally want to put it on Amazon, I could see a lot of people buying it, not realizing what they're getting and feeling ripped off when it was not good. [00:47:00] Jeremy: Yeah, I mean, I, I don't know, if it's an issue with the, the technical stuff. It probably is. But I, I know they've definitely had problems where, fiction, they have people just generating hundreds, thousands of books, submitting them all, just flooding it. [00:47:13] David: Seeing what happens. [00:47:14] Jeremy: And, um, I think that's probably... That's probably the main reason why they ask you, cause they want you to say like, uh, yeah, you said it wasn't. And so now we can remove your book. [00:47:24] David: right. Right. Yeah. Yeah. [00:47:26] Jeremy: I mean, it's, it's not quite the same, but it's similar to, I don't know what Stack Overflow's policy is now, but, when the large language model stuff started getting big, they had a lot of people answering the questions that were just. Pasting the question into the model [00:47:41] David: Which because they got it from [00:47:42] Jeremy: and then [00:47:43] David: The Got model got it from Stack Overflow. [00:47:45] Jeremy: and then pasting the answer into Stack Overflow and the person is not checking it. Right. So it's like, could be right, could not be right. Um, cause, cause to me, it's like, if, if you generate it, if you generate the answer and the answer is right, and you checked it, I'm okay with that. [00:48:00] David: Yeah. Yeah. [00:48:01] Jeremy: but if you're just like, I, I need some karma, so I'm gonna, I'm gonna answer these questions with, with this bot, I mean, then maybe [00:48:08] David: I could have done that. You're not adding anything. Yeah, yeah. [00:48:11] Jeremy: it's gonna be a weird, weird world, I think. [00:48:12] David: Yeah, no kidding. No kidding. [00:48:15] Jeremy: that's a, a good place to end it on, but is there anything else you want to mention, [00:48:19] David: No, I think we covered it all just yeah, you could find me online. I'm Davetron5000 on Ruby. social Mastodon, I occasionally post on Twitter, but not that much anymore. So Mastodon's a place to go. [00:48:31] Jeremy: David, thank you so much [00:48:32] David: All right. Well, thanks for having me.

“We need to change our ways of working to give importance to the work quality that we deliver, ensure we keep raising our bar, and pass it on to the next generation of developers." Srihari Sridharan is a software architect and the author of “Craft Your Code”. In this episode, we discussed software craftsmanship and how to become better software engineers. Srihari first began by sharing the relationship between software craftsmanship and high-quality code. He described some practices for improving code quality, such as establishing coding standards, improving code readability, doing effective code review, and managing technical debt. He also explained the importance of software engineers understanding different architectural styles and domain knowledge. Srihari also shared strategies for creating high-performing teams by establishing psychological safety and trust.   Listen out for: Career Journey - [00:03:08] Bridging the Students Gap with Industry - [00:06:11] Writing “Craft Your Code” - [00:09:36] Software Craftsmanship and High Quality Code - [00:12:18] Root Causes of Low Quality Code - [00:15:26] Coding Standards - [00:20:15] Code Aesthetics - [00:24:17] Code Readability - [00:28:09] Tabs vs Spaces - [00:32:31] Code Review - [00:34:12] Managing Technical Debt - [00:39:36] Psychological Safety & Trust - [00:46:23] Mind Maps - [00:52:09] Architecture & Domain Knowledge - [00:54:00] 3 Tech Lead Wisdom - [01:02:33] _____ Srihari Sridharan's BioSrihari Sridharan is a Software Architect and Engineer with a hands-on approach. He is a speaker, conducting courses and delivering talks on software craftsmanship and writing clean code. Srihari's areas of expertise encompass refactoring, design patterns, enterprise application architectural patterns, integration patterns, and cloud-native design patterns. Srihari is also a reviewer and a senior technical proof-reader for Manning Publications Co, and he serves as a member of the ‘Board of Studies - Department of Information Technology' at B.S Abdur Rahman Crescent Institute of Science & Technology. Residing in Chennai with his wife Swathy and son Advaith, Srihari enjoys spending quality time with his family. In his leisure time, he loves playing cricket, writing blogs, reading books, and cooking. Follow Srihari: Website – https://topmate.io/srihari_sridharan LinkedIn – linkedin.com/in/srihari-sridharan/ _____ Our Sponsors Miro is your team's visual workspace to connect, collaborate, and create innovations together, from anywhere.Sign up today at miro.com/podcast and get your first 3 Miro boards free forever. Like this episode? Show notes & transcript: techleadjournal.dev/episodes/152 Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.

In this episode of the Modern Web Podcast, Rob Ocel dives into the intricate world of reliability engineering in software development with Maggie Johnson-Pint, co-founder of Stanza Systems. Uncover the secret behind the stampede effect that can cripple your application during traffic surges and gain insights into the indispensable need for a balanced blend of proactive and reactive strategies to ensure unwavering reliability. Reliability engineering goes beyond mere availability metrics, encompassing user experience, performance, and trustworthiness. While the giants of the industry like Google and Silicon Valley enterprises discuss it at length, the broader developer community often finds these concepts elusive. Stanza deciphers the code to crafting resilient systems that sail through unexpected challenges and observability that unveils the hidden dynamics of your software. Picture a scenario where your system functions flawlessly until it's pushed to its limits. Stanza's solution: wield the power of rate limiting and masterful traffic management. Empower your application to scale seamlessly, even during maintenance or surges in demand. Don't let downtime tarnish your reputation – keep the traffic flowing while maintaining control. But that's not all – we introduce you to Stanza, the game-changing tool designed to bring reliability optimization to your fingertips. Stanza revolutionizes the way web developers navigate the intricate world of performance. Imagine dynamically fine-tuning content delivery based on system load. Drawing inspiration from industry giants like Netflix, this approach enhances perceived reliability while alleviating system stress. Whether you're a part of a small team or a burgeoning enterprise, Stanza's integration fits seamlessly into diverse tech stacks, including serverless environments. It's your all-in-one solution, offering features like request limiting, prioritization, and real-time adjustments. We're here to demystify complex concepts, paving the way for a brighter, more reliable digital landscape. Elevate your application's reliability, user experience, and performance to unparalleled heights. Embrace the synergy of proactive and reactive measures with the roadmap laid out in this interview. Experience the transformation – explore Stanza and unlock a new era of software reliability! This Dot Labs is a development consultancy that is trusted by top industry companies, including Stripe, Xero, Wikimedia, Docusign, and Twilio. This Dot takes a hands-on approach by providing tailored development strategies to help you approach your most pressing challenges with clarity and confidence. Whether it's bridging the gap between business and technology or modernizing legacy systems, you'll find a breadth of experience and knowledge you need. Check out how This Dot Labs can empower your tech journey at thisdot.co. Host Rob Ocel, Software Architect at This Dot Labs Guest Maggie Johnson-Pint, Co-Founder of Stanza Systems

Dennis van der Stelt is a Software Architect who loves building distributed systems and the challenges they bring. To be better than the day before, he continuously searches for new ways to improve his knowledge of architecture and software development. What he learns he tries to share via numerous articles, presentations, and posts on his blog. If you want to chat, feel free to ping Dennis on Twitter at @dvdstelt.   Topics of Discussion: [3:07] How did Dennis get into distributed systems? [5:24] Helping customers with building distributed systems. [7:00] Dennis describes the essence of distributed systems. [9:07] The role of asynchronous messaging between components in distributed systems. [12:38] Dennis shares a story about a panicked CEO when the database went down, and the lessons learned from the experience. [14:44] Starting with synchronous distribution, and then moving to asynchronous when you find the benefit. [16:05] The downsides of using asynchronous communication. [17:28] Who decides what happens when things go wrong? [22:34] What Amazon does right. [27:18] Microservices and event-driven architecture — Jeffrey has yet to find a microservices expert! [35:48] Thinking more about the domain model in vertical slices.   Mentioned in this Episodes: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us 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! Architect Tips — Video podcast! Azure DevOps Particular Software Dennis on Github Dennis on Twitter Dennis van der Stelt   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Andrew Knight, popularly known as automation panda, was recently interviewed on the Modern Web Podcast by host Rob Ocel. Andrew, a software quality champion, developer advocate, and test automation expert, shared his insights and experiences in the interview. He spoke passionately about testing and the importance of improving software quality. Andrew discussed the challenges he faced early in his career and how he recognized the opportunity to enhance software stability, readability, and speed through effective testing. The conversation then shifted to the current state of testing in various tech communities. Andrew highlighted the wide variation in testing practices across companies, irrespective of programming languages or tech stacks. Smaller companies often lacked proper testing processes, while larger companies relied on traditional testing approaches that were deeply ingrained. Advancements in web testing frameworks and tools were another topic of discussion. Andrew acknowledged the long-standing availability of functional testing, which simulates user interactions with a website. However, he pointed out the emergence of newer tools like Cypress and Playwright, which provide a modern developer experience, making web testing more accessible, efficient, and enjoyable. Andrew also emphasized the importance of addressing user experience and visual aspects of testing, where human evaluation remains crucial but can be supplemented by visual testing tools like Applitools. The interview concluded with a glimpse into the future of autonomous testing. Andrew highlighted that while autonomous testing could never completely replace human exploratory testing, it held potential in understanding the behavior of software applications. The vision was to train autonomous agents to recognize established workflows, adapt to specific applications, propose test cases based on observed behaviors, and potentially execute these behaviors autonomously. This approach would allow developers to focus more on designing desired behaviors and less on implementing specifications. Throughout the interview, Rob Ocel and Andrew Knight discussed the trade-off between investment and return in software testing. They reflected on the value of maintaining extensive test coverage and questioned its significance compared to the effort required to sustain it. Andrew emphasized the importance of focusing on valuable behaviors and understanding customer needs when prioritizing testing efforts. They also touched upon the idea that not all edge cases or hypothetical scenarios warrant investing time and resources in testing if they have minimal real-world impact. Other topics covered in the interview include Andrew's talk on the eight Software Testing convictions, inspired by Japanese woodblock prints, which emphasize intentional design, accessibility, and the value of quality in software development. The discussion also revolved around the value of personas, engaging with real users to understand their needs and prioritize testing efforts accordingly. The interview highlighted the delicate balance between investing in quality and delivering value in software development and testing, with a focus on valuable behaviors and iterative learning from user interactions.   Host Rob Ocel, Software Architect at This Dot Labs   Guest Andrew Knight, Principal Developer Advocate at Applitools   This episode is sponsored by This Dot Labs.  

Tara Hernandez, Vice President Developer Productivity @ MongoDB, sits down with Kelly Anlas, Engineering Manager @ Paxos, Rafna Bash, CEO/Mentor @ Aktibeto, Anne Kilzner, Software Architect, and Bisi Josh-Falade, AI Solutions Consultant for their conversation, “Unexpectedly Open To Work.” They discuss the positive outcomes of getting laid off, balancing a job search with everyday life and upskilling to get ready for a new job.

“Spend some time looking at the system in which you work. Understand how the work is working. Understand how flow is for your organization. And then you can work to optimize that." James Lewis is a Director at ThoughtWorks and a pioneer of microservice architecture. In this episode, we went back memory lane to the time when James first coined and popularized the microservice architecture. James described his definition of a microservice and its important characteristics. He also shared the recent microservice evolution, including the swing between microservice and monolith. In the second half, James shared his insights from complexity science related to different scaling patterns. Particularly, he explained how different hierarchy types can affect an organization's growth rate. Towards the end, James gave some tips on how organization can detect signs of suboptimal growth and what we can do to maintain organizational agility.   Listen out for: Career Journey - [00:03:48] Coining Microservices - [00:07:25] Definition of Microservices - [00:14:13] Microservices Swing - [00:18:42] Scaling Law and Complexity Science - [00:24:05] Complex and Adaptive System - [00:40:01] Examining Sublinear Growth - [00:43:47] 3 Tech Lead Wisdom - [00:51:19] _____ James Lewis's BioJames is a Software Architect and Director at Thoughtworks based in the UK. He's proud to have been a part of Thoughtworks' journey for fourteen years and it's ongoing mission of delivering technical excellence for its clients and in amplifying positive social change for an equitable future. As a member of the Thoughtworks Technical Advisory Board, the group that creates the Technology Radar, he contributes to industry adoption of open source and other tools, techniques, platforms and languages. He is an internationally recognised expert on software architecture and design and on its intersection with organisational design and lean product development. After defining what was the newly emerging Microservices architectural style back in 2014, James' primary consulting focus these days is helping organisations with technology strategy, distributed systems design and adoption of SOA. Follow James Lewis: Twitter – @boicy LinkedIn – linkedin.com/in/james-lewis-microservices/ Email – james.lewis@thoughtworks.com _____ Our Sponsors Are you looking for a new cool swag? Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available. Check out all the cool swags available by visiting techleadjournal.dev/shop. And don't forget to brag yourself once you receive any of those swags. Like this episode? Show notes & transcript: techleadjournal.dev/episodes/135 Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.

In this episode, Rob Ocel is joined by Rick Conrades, Engineering Manager at This Dot Labs, to discuss software development and engineering management! They discuss how to identify and mitigate risks, how to make difficult technology tradeoffs, and how to "manage up"! Finally, they share tips for all software engineers about relating to engineering managers, and the surprising challenges that engineering managers face with their teams. Guest Rick Conrades, Engineering Manager at This Dot Labs Host Rob Ocel, Software Architect and Engineering Lead at This Dot Labs Sponsored by This Dot Labs

In this episode, hosts Rachel and Tommy have a conversation with Immigration Resource Network leaders Shivani Tamkiya, Software Engineer for NPS, Krishna Amilineni, Software Architect for FACTS SIS, and Aayush Khatiwada, Software Engineer for Nelnet Campus Commerce. They discuss how the Immigration Resource Network helps associates and their families during the process of immigrating to the United States by offering connection, support, and resources. Any associates who have questions about the immigration process are also welcome to contact Lisa Meyer or Viridiana Guillen in our People Services department!

In this episode, Rob Ocel is joined by Dominik Dorfmeister (Frontend Tech Lead at Adverity and Maintainer of TanStack Query), to talk about open-source software, TanStack Query, and more! They discuss the rapid growth of the TanStack, how Dominik first became involved as a core team maintainer and the challenges he's faced, the future of the TanStack and data-management as a driving force in front-end framework development, using TanStack in other frameworks, and the joys of skiing. Guest Dominik Dorfmeister, Frontend Lead at Adverty and Maintainer for TanStack Query Host Rob Ocel, Software Architect and Engineering Lead at This Dot Labs Sponsored by This Dot Labs

In this episode, Jesse Tomchak is joined by Tanner Linsley of smash hits like TanStack Table, Query, and Router, for a discussion about Tanner's latest project: TanStack Start. Tanner discusses the problems he's trying to solve, how building on existing ideas in the community has accelerated development pace, and how he went about solving it in a very "TanStack" fashion. Guest Tanner Linsley, Co-Founder at nozzle.io and Creator of TanStack Host Jesse Tomchack, Software Architect at This Dot Labs   Sponsored by This Dot Labs

On this episode of The Modern Web, we catch up with Scott Spence, Developer Relations Engineer at Storyblok, and SvelteSociety London meetup organizer. We dive into the ins and outs of Svelte, ramping up from React, what's it like to a second career developer, and the importance of paying it forward to developers who are new to the community.   Guest Scott Spence, Developer Relations Engineer at Storyblok   Host Jesse Tomchak, Software Architect at This Dot Labs   Sponsored by This Dot Labs

This week on Modern Web Alyssa Nicoll from Progress takes the web out of the browser and into native apps. Bringing you the cutting edge of native applications with embedded web technologies, Angular offers the best of both worlds. We take some minor detours into learning backend technology stacks as a long life JavaScript developer, and the awesome communities and friends we've made along the way. Join us for a spectacular journey and a couple tangents.   Guest Alyssa Nicoll, Sr. Developer Advocate at Progress   Host Jesse Tomchak, Software Architect at This Dot Labs   Sponsored by This Dot Labs

Jeff Doolittle is a software architect, transformational leader, and se-radio.net host who's on a mission to make good software professionals great.Jeff joined me on Ditching Hourly to talk about his journey from a web dev working for free pizza to an in-demand software architect.Along the way, we talked about the importance of strategy, systems thinking as applied to software, and finding a balance between “wonk” and “geek” in order to deliver real business value.Related Links Jeff's website Jeff's LinkedIn Jeff's Twitter Jeff's Github Exploring Requirements: Quality Before Design On the Criteria To Be Used in Decomposing Systems into Modules iDesign.net Lean Software Systems Engineering for Developers Thinking in Systems: A Primer ----Do you have questions about how to improve your business? Things like: Value pricing your work instead of billing for your time? Positioning yourself as the go-to person in your space? Productizing your services so you never have to have another awkward sales call or spend hours writing another custom proposal? Book a one-on-one coaching call with me and get answers to these questions and others in the time it takes to get ready for work in the morning.Best of all, you're covered by my 100% satisfaction guarantee. If at the end of the call, you don't feel like it was worth it, just say the word, and I'll refund your purchase in full.To book your one-on-one coaching call, go to: https://jonathanstark.com/callI hope to see you there!

On Today's Show:  "The first step is realizing that the first decision you make won't be your last. There's not a perfect solution out there. There are a lot of variables to consider when we build a system or solution. We can't just pick the hot new thing because it might not be mature enough or it might not work in our customer space." - Paul Burnette. There's a lot of care and big decisions that go into successful software planning for an organization. Changes in the software world happen at an astounding pace. It's not only important to pick the right solutions for today, but also to think about resiliency in the future. Not to mention finding the right solutions that fit in with the tech landscape already present in an organization without sacrificing practicality or efficiency. Today, Paul Burnette, Vice President of the Software Accelerator, and Drew Formica, Software Architect at Leidos join to share why it's so important for organizations to keep up with software tech and how they can do it in a way that keeps workflows fast and ready for the future.  Key TakeawaysWhat Mission Software isThe importance of keeping up to date with softwareWhy looking to the future is crucial when finding solutions. Linkswww.leidos.com/software