POPULARITY
19 episodes with redmonk
12 episodes with redmonk
5 episodes with redmonk
14 episodes with redmonk
6 episodes with redmonk
15 episodes with redmonk
2 episodes with redmonk
3 episodes with redmonk
2 episodes with redmonk
On this Screaming in the Cloud Replay, Corey is joined by James Governor, co-founder of RedMonk. In this throwback, they discuss how RedMonk is different from traditional analyst firms. You'll also learn how Corey and James met, how James credentialed Corey as a bona fide industry analyst on Twitter, and how anyone can be an analyst in theory. Beyond that, James explains the mindset required to give advice as an analyst, what attracted him to becoming an analyst in the first place, and why RedMonk focuses on the qualitative instead of the quantitative.Show Highlights(0:00) Intro(0:29) The Wiz sponsor read(1:31) What lead James to become an analyst and founding RedMonk(4:36) Why James believes developers are the “ new monarchmakers”(10:06) Recounting the time James credentialed Corey as an analyst on Twitter(12:24) Who and what are analysts?(17:44) The woes of rage-driven development(21:01) The Wiz sponsor read(21:55) Why Corey thinks James is a model Twitter user and advocate(25:23) What makes RedMonk's industry events stick out from everyone else(35:15) Why James habitually changes his name on Twitter(36:45) Where you can find more from JamesAbout James GovernorJames Governor founded RedMonk in 2002 with Stephen O'Grady. They focus on developers as the real key influencers in tech. Understanding that people choose technology because of gut instincts not facts per se. As an ex-journalist, James has managed teams and news agendas in the weekly publication grind. He has also been IBM and MS watcher since 1995.LinksRedMonk: https://redmonk.com/James's Twitter: https://twitter.com/MonkChipsMonktoberfest: https://monktoberfest.com/Monki Gras: https://monkigras.com/Original Episodehttps://www.lastweekinaws.com/podcast/screaming-in-the-cloud/analyzing-analysts-with-james-governor/SponsorThe Wiz: wiz.io/scream
Welcome to another engaging episode of Maintainable! Robby sits down with Kate Holterhoff, Ph.D., a Senior Analyst at RedMonk and former front-end engineer, to explore the intricate world of software maintenance, documentation, and the future of developer roles. Kate brings her unique perspective from her time as a practitioner at a digital marketing agency, her academic background, and her current role in developer advocacy.Topics Explored[00:00:00] Introduction to Kate's Background: Robby and Kate discuss her journey from academia to front-end engineering and now to being a Senior Analyst at RedMonk. Kate shares how her experiences have shaped her perspective on software maintenance.[00:04:00] Well-Maintained Software: Kate dives into her definition of well-maintained software, emphasizing modularity, semantic readability, and the importance of considering future developers who will interact with the code.[00:11:30] The Challenges of Agency Work: Kate reflects on her time at a digital marketing agency, where she often worked on projects that had passed through many hands. She discusses the importance of balancing quick deliverables with maintainability.[00:20:45] The Role of Documentation: Kate shares insights on the value of documentation for distributed teams, highlighting her experience organizing documentation sessions ("documentation paloozas") to capture team knowledge and ensure maintainability.[00:30:00] RedMonk and Developer Advocacy: Kate explains her role at RedMonk and how the firm differs from traditional analyst firms like Gartner. She discusses RedMonk's focus on developers as key decision-makers in the tech landscape.[00:39:15] Front-End Developers as Kingmakers: Robby and Kate explore how front-end engineers are increasingly influencing the adoption of tools and technologies within organizations. Kate describes this trend as front-end developers becoming "kingmakers" in the industry.[00:49:50] AI and Developer Tools: Kate discusses the integration of AI into developer tools, the potential benefits, and challenges for junior developers. She emphasizes the importance of understanding how to read code in an AI-assisted world.Key Takeaways:Emphasize modularity and semantic readability to ensure code can be easily maintained by future developers.Documentation is crucial for maintainability, especially in distributed and contractor-heavy teams.Front-end developers are becoming key decision-makers, influencing tool and technology adoption.AI is increasingly integrated into developer workflows, making it essential for developers to focus on reading and understanding code.The definition of a 'developer' is evolving, with more abstracted tools and AI playing a larger role in development processes.Resources Mentioned:RedMonkKate Holterhoff on LinkedInKate Holterhoff on TwitterDarwin's The Origin of SpeciesEpisode Highlights:[00:00:00] Introduction to Kate's Background[00:04:00] Characteristics of Well-Maintained Software[00:20:45] The Importance of Documentation[00:30:00] What Does a Senior Analyst at RedMonk Do?[00:39:15] Front-End Developers as Kingmakers[00:49:50] The Role of AI in Developer ToolsThanks 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.
The Cursor AI code editor raises $60 million, RedMonk's Rachel Stephens tries to determine if rug pulls are worth it, Caleb Porzio details how he made $1 million on GitHub Sponsors, Elastic founder Shay Banon announces that Elasticsearch is open source (again) & Tomas Stropus writes about the art of finishing.
The Cursor AI code editor raises $60 million, RedMonk's Rachel Stephens tries to determine if rug pulls are worth it, Caleb Porzio details how he made $1 million on GitHub Sponsors, Elastic founder Shay Banon announces that Elasticsearch is open source (again) & Tomas Stropus writes about the art of finishing.
The Cursor AI code editor raises $60 million, RedMonk's Rachel Stephens tries to determine if rug pulls are worth it, Caleb Porzio details how he made $1 million on GitHub Sponsors, Elastic founder Shay Banon announces that Elasticsearch is open source (again) & Tomas Stropus writes about the art of finishing.
This week, we discuss our AI usage, recap key announcements from VMware Explore, and examine RedMonk's analysis of how open-source licensing impacts revenue and market cap. Plus, some thoughts on power bricks. Watch the YouTube Live Recording of Episode (https://www.youtube.com/live/eb85zwGi-I8?si=obl5uvVehHdNZYQ8) 482 (https://www.youtube.com/live/eb85zwGi-I8?si=obl5uvVehHdNZYQ8) Runner-up Titles Information wants to be free, yo Stay In The Bushes Tip Jar Culture Tell Me About Meatloaf I want you in here with me Platforms For Building Platforms Private SaaS Mom and Dad having a fun conversation on a road trip I have my special chargers I want it back Rundown Sign up for Coté's Newsletter (https://newsletter.cote.io) IDC's Worldwide AI and Generative AI Spending (https://blogs.idc.com/2024/08/21/idcs-worldwide-ai-and-generative-ai-spending-industry-outlook/) Private Cloud at VMware Explore - Notebook (https://newsletter.cote.io/p/private-cloud-at-vmware-explore-notebook) Cursor.com (https://newsletter.cote.io) OSS Software Licensing Changes and Their Impact on Financial Outcomes (https://redmonk.com/rstephens/2024/08/26/software-licensing-changes-and-their-impact-on-financial-outcomes/) Coté's proposal for how to fix it (https://softwaredefinedtalk.slack.com/archives/C5GPMBXQT/p1724827874689099). Another Thread from Adam Jacob on OSS (https://x.com/adamhjk/status/1828150343332700223) Zoom Docs Is Here. Is It Any Good? (https://gizmodo.com/zoom-docs-vs-google-docs-2000490313) Relevant to your Interests Apple's App Store Head to Leave in Reorganization Amid Global Scrutiny (https://www.bloomberg.com/news/articles/2024-08-21/apple-s-app-store-head-to-leave-in-reorganization-amid-global-scrutiny) Snowflake Outlook Fails to Ease Investor Fears of Competition (https://www.bloomberg.com/news/articles/2024-08-21/snowflake-outlook-fails-to-ease-investor-fears-of-competition) Microsoft revamps reporting structure to give better visibility into cloud consumption revenue (https://www.cnbc.com/2024/08/21/microsoft-changes-reporting-to-boost-cloud-consumption-visibility.html) More than 28% of Americans are searching for new jobs — the highest rate in a decade (https://www.nbcnews.com/business/economy/28-americans-are-now-searching-new-job-highest-rate-decade-rcna167368) Microsoft is reportedly making more branding changes for Copilot business services (https://www.neowin.net/news/microsoft-is-reportedly-making-more-branding-changes-for-copilot-business-services/) SolarWinds left hardcoded credentials in helpdesk product (https://www.theregister.com/2024/08/22/hardcoded_credentials_bug_solarwinds_whd/) Intel has hired Morgan Stanley, other advisers for activist defense (https://www.cnbc.com/2024/08/23/intel-intc-activist-defense-sources.html) The Future of the Trade Show Industry – Are We In Danger of Losing Our Soul? (https://tsnn.com/experts-opinions/future-trade-show-industry-%E2%80%93-are-we-danger-losing-our-soul) The massive Social Security number breach is actually a good thing (https://www.vox.com/technology/367986/freeze-credit-equifax-experian-transunion-ssn-breach) Continuous reinvention: A brief history of block storage at AWS (https://www.allthingsdistributed.com/2024/08/continuous-reinvention-a-brief-history-of-block-storage-at-aws.html) Grafana Labs raises $270M (https://techcrunch.com/2024/08/21/grafana-labs-is-now-valued-at-6b/) Capt. Grace Hopper on Future Possibilities: Data, Hardware, Software, (https://www.nsa.gov/helpful-links/nsa-foia/declassification-transparency-initiatives/historical-releases/view/article/3880193/capt-grace-hopper-on-future-possibilities-data-hardware-software-and-people-1982/) Rackspace Goes All In – Again – On OpenStack (https://www.nextplatform.com/2024/08/22/rackspace-goes-all-in-again-on-openstack/) Sonos App Debacle Leaves Company Racing to Save Its Reputation (https://www.bloomberg.com/opinion/articles/2024-08-22/sonos-app-issues-leave-company-racing-to-save-its-reputation) Nonsense Chick-fil-A Opens First Elevated Drive-Thru Concept (https://www.chick-fil-a.com/press-room/chick-fil-a-opens-first-elevated-drive-thru-concept) How Costco Hacked the American Shopping Psyche (https://www.nytimes.com/2024/08/20/dining/costco.html) NASA Picks SpaceX to Rescue Astronauts Marooned in Space (https://www.bloomberg.com/news/articles/2024-08-24/spacex-selected-by-nasa-to-rescue-astronauts-marooned-in-space) The startup teaching your computer how to smell (https://thehustle.co/news/the-startup-teaching-your-computer-how-to-smell) Conferences DevOpsDays Antwerp (https://devopsdays.org/events/2024-antwerp/welcome/), Coté Speaking, Sept 4–5, 2024, 15th anniversary. Civo Navigate Europe, Berlin (https://www.civo.com/navigate/europe), Sept 10-11, 2024. SREday London 2024 (https://sreday.com/2024-london/), Sept 19–20, 2024. Coté speaking, 20% off with code SRE20DAY. Cloud Foundry Day EU (https://events.linuxfoundation.org/cloud-foundry-day-europe/), Karlsruhe, GER, Oct 9, 2024, 20% off with code CFEU24VMW. SREday Amsterdam (https://sreday.com/2024-amsterdam/), Nov 21st, 2024. Coté speaking (https://sreday.com/2024-amsterdam/Michael_Cote_VMwarePivotal_We_Fear_Change), 20% off with code SRE20DAY. SDT News & Community Join our Slack community (https://softwaredefinedtalk.slack.com/join/shared_invite/zt-1hn55iv5d-UTfN7mVX1D9D5ExRt3ZJYQ#/shared-invite/email) Email the show: questions@softwaredefinedtalk.com (mailto:questions@softwaredefinedtalk.com) Free stickers: Email your address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) Follow us on social media: Twitter (https://twitter.com/softwaredeftalk), Threads (https://www.threads.net/@softwaredefinedtalk), Mastodon (https://hachyderm.io/@softwaredefinedtalk), LinkedIn (https://www.linkedin.com/company/software-defined-talk/), BlueSky (https://bsky.app/profile/softwaredefinedtalk.com) Watch us on: Twitch (https://www.twitch.tv/sdtpodcast), YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured), Instagram (https://www.instagram.com/softwaredefinedtalk/), TikTok (https://www.tiktok.com/@softwaredefinedtalk) Book offer: Use code SDT for $20 off "Digital WTF" by Coté (https://leanpub.com/digitalwtf/c/sdt) Sponsor the show (https://www.softwaredefinedtalk.com/ads): ads@softwaredefinedtalk.com (mailto:ads@softwaredefinedtalk.com) Recommendations Brandon: Ozlo Sleepbuds (https://ozlosleep.com/). Coté: Ori (https://www.youtube.com/watch?v=Uiqb8q02ZSw)ginal Cloud Foundry launch videos, April, 2011 (https://www.youtube.com/watch?v=Uiqb8q02ZSw). Photo Credits Header (https://unsplash.com/photos/shallow-focus-photography-of-white-travel-adapter-ZUabNmumOcA) Artwork (https://unsplash.com/photos/assorted-coin-lot-in-clear-glass-jar-0htQSq0TVB0)
In this episode, we chat with Luis Villa, co-founder of Tidelift, about everything from supporting open source maintainers to coding with AI. Luis, a former programmer turned attorney, shares stories from his early days of discovering Linux, to his contributions to various projects and organizations including Mozilla and Wikipedia. We discussed the critical importance of open source software, the challenges faced by maintainers, including burnout, and how Tidelift works toward compensating maintainers. We also explore broader themes about the sustainability of open source projects, the impact of AI on code generation and legal concerns, and the need for a more structured and community-driven approach to long-term project maintenance. 00:00 Introduction 03:20 Challenges in Open Source Sustainability 07:43 Tidelift's Role in Supporting Maintainers 14:18 The Future of Open Source and AI 32:44 Optimism and Human Element in Open Source 35:38 Conclusion and Final Thoughts Guest: Luis Villa is co-founder and general counsel at Tidelift. Previously he was a top open source lawyer advising clients, from Fortune 50 companies to leading startups, on product development, open source licensing, and other matters. Luis is also an experienced open source community leader with organizations like the Wikimedia Foundation, where he served as deputy general counsel and then led the Foundation's community engagement team. Before the Wikimedia Foundation, he was with Greenberg Traurig, where he counseled clients such as Google on open source licenses and technology transactions, and Mozilla, where he led the revision of the Mozilla Public License. He has served on the boards at the Open Source Initiative and the GNOME Foundation, and been an invited expert on the Patents and Standards Interest Group of the World Wide Web Consortium and the Legal Working Group of OpenStreetMap. Recent speaking engagements include RedMonk's Monki Gras developer event, FOSDEM, and as a faculty member at the Practicing Law Institute's Open Source Software programs. Luis holds a JD from Columbia Law School and studied political science and computer science at Duke University.
Kate Holterhoff - an analyst from RedMonk - shares why frontend developers are increasingly dictating the adoption of new developer tools.Kate shares specific examples, including Supabase. Links:Frontend Developers: the Newest New Kingmakers https://redmonk.com/kholterhoff/2024/02/15/frontend-developers-the-newest-new-kingmakers/Kate's website https://www.kateholterhoff.com/RedMonk https://redmonk.com/Kate's Twitter/X https://x.com/KateHolterhoff
Welcome to MongoDB.local New York! Join host Shane McAlister, as he engages in a lively discussion with Stephen O'Grady, Principal Analyst and Co-Founder of RedMonk. Recorded live from the show floor, this episode dives into the latest trends in developer experiences, the transformative impact of AI, and the exciting announcements from MongoDB, including vector search and enhancements in MongoDB 8.0.
Send us a Text Message.Rachel Stephens is a Senior Analyst at RedMonk, where she covers emerging growth technologies and markets while helping clients understand and contextualize technology adoption trends. In this conversation, we discuss tech debt, layoffs, software development trends, and more.Where to find RachelLinkedIn: https://www.linkedin.com/in/rachelstephens/Twitter: https://twitter.com/rstephensmeRedMonk: https://redmonk.com/rstephens/author/rstephens/Follow, Like, and Subscribe!Podcast: https://www.thecloudgambit.com/YouTube: https://www.youtube.com/@TheCloudGambitLinkedIn: https://www.linkedin.com/company/thecloudgambitTwitter: https://twitter.com/TheCloudGambitTikTok: https://www.tiktok.com/@thecloudgambitShow LinksLessons Learned: https://atlassianblog.wpengine.com/wp-content/uploads/2024/01/lessonslearned.pdfAI, Code Generation: https://stackoverflow.blog/2024/06/10/generative-ai-is-not-going-to-build-your-engineering-team-for-you/Zach Akil: https://www.zackakil.com/
In this episode of "Screaming in the Cloud," Corey Quinn is joined by Rachel Stephens, a Senior Analyst at RedMonk, for an engaging conversation about the profound impact of AI on software development. Rachel provides her expert insights on programming language trends and the shifts in the tech landscape driven by AI. They look into how AI has reshaped coding practices by automating mundane tasks and offering real-time assistance, altering how developers work. Furthermore, Corey and Rachel examine the economic and practical challenges of incorporating AI into business operations, aiming to strip away the hype and highlight AI technology's capabilities and constraints.Show Highlights: (00:00) - Introducing Rachel Stephens, Senior Analyst at RedMonk(00:28) - The Humorous Nemesis Backstory(03:42) - AI, focusing on its broad impact and current trends in technology(04:54) - Corey discusses practical applications of AI in his work(06:00) - Rachel discusses how AI tools have revolutionized her workflow(08:12) - RedMonk's approach to tracking language rankings(10:29) - Public vs. Internal Use of Programming Languages(13:09) - Rachel and Corey discuss how AI coding assistants are improving coding consistency and efficiency(15:55) - Corey challenges the purpose of language rankings (20:51) - AI tools affecting traditional data sources like Stack Overflow (26:28) - The challenges of measuring productivity in the AI era(29:21) - The macroeconomic impacts on tech employment and the role of AI in workforce management(36:33) - Rachel and Corry share their personal uses and preferences for AI tools(39:25) - Closing Remarks and where to reach RachelAbout Rachel: Rachel Stephens is a Senior Analyst with RedMonk, a developer-focused industry analyst firm. She focuses on helping clients understand and contextualize technology adoption trends, particularly from the lens of the practitioner. Her research covers a broad range of developer and infrastructure products., Rachel Stephens is a Senior Analyst with RedMonk, a developer-focused industry analyst firm. She focuses on helping clients understand and contextualize technology adoption trends, particularly from the lens of the practitioner. Her research covers a broad range of developer and infrastructure products.Links Referenced: RedMonk: https://redmonk.com/Rachel Stephens LinkedIn: https://www.linkedin.com/in/rachelstephens/* Sponsor Prowler: https://prowler.com
Tom Raftery and Joe Lynch discuss triple bottom line logistics. Tom is an entrepreneur, sustainability expert, technology executive and all-around thought leader. Tom advises logistics and supply chain companies on technology, sustainability, and communications Summary: Triple Bottom Line Logistics Tom Raftery, a sustainability expert, discusses the importance of triple bottom line logistics in the supply chain industry. He explains how reducing emissions and making operations more sustainable can lead to cost savings and improved profitability. Raftery shares his journey and insights on how companies can achieve a triple bottom line by utilizing forecasting, technology, and optimizing routes and loads. The podcast also explores the transition towards electric vehicles in various segments and strategies for reducing product returns in e-commerce. Raftery emphasizes the need for companies to start their sustainability journey now to remain competitive in the face of increasing pressures from stakeholders and regulations. #TripleBottomLineLogistics #SustainableSupplyChain #ReducingEmissionsInLogistics About Tom Raftery Tom Raftery is a preeminent Sustainability & Technology Executive, Influential Podcast Host of the highly regarded Climate Confident and Sustainable Supply Chain podcasts, and a recognised Thought Leader. As well as being an influential international keynote speaker Tom is a guest lecturer at the prestigious Instituto Internacíonal San Telmo, board advisor for various startups, and former Global Vice President at SAP. Prior to joining SAP, Tom built a successful career as an independent industry analyst, focusing on the Internet of Things, Energy, and CleanTech, while also serving as a Futurist for Gerd Leonhardt's Futures Agency. With an extensive background in technology and social media dating back to 1991, Tom has co-founded an Irish software development company, a social media consultancy, and the hyper energy-efficient data center, Cork Internet eXchange. Additionally, Tom has made significant contributions to the field of sustainability through his work as an Analyst at industry analyst firm RedMonk, where he led their Sustainability practice for over seven years. His unique blend of expertise and experience makes him a sought-after thought leader in technology, sustainability, and social media. Key Takeaways: Triple Bottom Line Logistics Learn about the concept of triple bottom line logistics and its importance in the supply chain industry Discover how reducing emissions is crucial for companies to remain competitive and attract top talent Understand the components of the triple bottom line: people, planet, and profit Explore how companies can achieve a triple bottom line by making their logistics operations more sustainable and efficient Learn how forecasting and technology can significantly reduce food waste, saving money and resources Gain insights into the transition towards electrification in the transportation industry, driven by advancements in battery technology and the pursuit of sustainability Discover strategies for making supply chains leaner and greener, including better forecasting, route and load optimization, electric vehicles, and reducing returns Timestamps (00:00:00) Triple Bottom Line Logistics (00:00:47) Sustainability and Technology in Supply Chain (00:04:17) Why Sustainability Matters in Logistics (00:10:14) Defining the Triple Bottom Line (00:12:10) Sustainability, Supply Chain, and Podcasting Journey (00:19:20) Sustainable Logistics: Efficiency Drives Profitability (00:23:56) Reducing Waste in Food Supply Chains (00:27:41) Fewer SKUs: A Sustainability Advantage (00:30:32) Reducing Emissions in Logistics (00:38:51) The Electrification of Transportation (00:44:22) The Transition to Electric Vehicles (00:47:24) Electrifying School Buses and Grid Balancing (00:51:04) Reducing E-commerce Returns with Better Sizing (00:55:59) Revolutionizing Online Shopping with 3D Modeling (00:58:23) Greening Supply Chains with Tom Raftery (01:00:13) Sustainability: A Journey You Must Start Learn More About Triple Bottom Line Logistics Tom Raftery | Linkedin Tom Raftery | Threads Tom Raftery | Twitter Tom Raftery | YouTube Channel Tom Raftery | Calendar Tom Raftery | Blog Tom Raftery | Newsletter Climate Confident podcast Sustainable Supply Chain podcast The Logistics of Logistics Podcast If you enjoy the podcast, please leave a positive review, subscribe, and share it with your friends and colleagues. The Logistics of Logistics Podcast: Google, Apple, Castbox, Spotify, Stitcher, PlayerFM, Tunein, Podbean, Owltail, Libsyn, Overcast Check out The Logistics of Logistics on Youtube
Danilo Campos, Proprietor of Antigravity, joins @quinnypig on Screaming in the Cloud to discuss his philosophy behind building tools that not only enhance developer experience but also improve the future of our world. Danilo shares his thoughts on how economic factors have influenced tech companies and their strategies for product, open source, and more. He also shares what he thinks is another, better way to approach these strategies, without ignoring the economic element. About DaniloDanilo Campos wants a world where technology makes us more powerful and expressive versions of ourselves. He worked with GitHub and the White House to deliver coding platforms to public housing residents, supported Glitch.com in its last days as an independent, and developed products for multiple early-stage startups, including Hipmunk. Today Danilo offers freelance developer experience services for devtools firms through Antigravity DX.Links Referenced: Antigravity DX: https://antigravitydx.com/ Blog: https://redeem-tomorrow.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn, and periodically on this show, we like to gaze into the future and tried to predict how that's going to play out. On this episode, I want to start off by instead looking into the past, more specifically my past. Before I started this place, I wound up working at a company called FutureAdvisor, which was a great startup for all of three months before we were bought by a BlackRock. I soon learned what a BlackRock actually was.While I was there, I encountered an awful lot of oral tradition around a guy named Danilo, and he—as it turned out—was a contractor who had been brought in to do a fair bit of mobile work. Meet my guest today, Danilo Campos, who is at present, the proprietor of a company called Antigravity DX. Thank you so much for joining me, I appreciate it.Danilo: Hey, Corey, it's good to be here.Corey: It's weird talking to you, just because you were someone that I knew by reputation, and if I were to take all the things that were laid at your feet after you no longer had been there, it feels like you were there for 20 years. What did you actually do there, and how long were you embedded for?Danilo: I loved the FutureAdvisor guys. I thought they were such a blast to work with. I loved what they were working on. I learned so much about how finance and investing works from FutureAdvisor, and somehow it was only seven months of my life. I'd been introduced to the founders as a freelance iOS developer at the time—this was 2014—and a guy I had worked with at Hipmunk actually put me in touch with these guys, and we connected. And they needed to get started doing mobile. They'd never done any mobile stuff, they didn't have anyone on staff who did mobile stuff.And by that point, I'd shipped I think, must have been half a dozen iOS native apps, and so I knew this stuff pretty well. I understood the workflows, I understood the path to getting from idea to shipped product, and they just wanted occasional help. How do we wireframe this? How do we plan the product that way? How do we structure this thing? And so, it started off as this just, kind of, occasional troubleshooting consulting thing.And I think about August 2014. They call me in for a meeting, they said, “Hey, we're stuck. We don't know how to get this thing off the ground. Could you help us get this project moving so that we actually ship it?” And so, I just came and embedded for seven months, and by the end of it, I was just running the entire iOS engineering team. We had a designer working with us. We had, I think it was four folks who were building the product. We had QA. It was a whole team to get this thing out the door. And we got it out the door after seven months of really working at it. And like I said, it was a blast. I love those folks.Corey: I have to be clear, when I say that I encountered a lot of what you had done. It was not negative. This was not one of those startups where there's a glorious tradition of assassinating the character out of everyone who has left the company—or at least Git repos—because they're not there to defend themselves anymore. There were times where decisions that you had made were highlighted as, “We needed to be doing things more like this.” There were times it was, “Oh, we can't do that because of how you wound up building this other thing.”And it was weird because it felt like you were the hand of some ancient deity, just moving things back and forth in your infinite wisdom of the ancients. It was unknowable, and we had to accept it as gospel, whether we liked it or not, at different times. In practice, I now know this was honestly just the outgrowth of a rapidly expanding culture where you've got to go from a team of five people to the team of 50 and keep everyone rowing in the same direction, ideally. But it was a really interesting social dynamic that I got to observe as a result, and I'm just tickled pink to be able to talk to you now. What are you doing these days?Danilo: Thank you for the context, by the way, because you know, I move on, as you do in a contract capacity, and you hope things work out.Corey: Yeah. To be clear, it was never a context of, “There's the bastard. Get him.” Like, that is not the perspective we are coming at this from at all.Danilo: Yeah, yeah, yeah. No, and it's hard because it was a very strange, alien codebase compared to the rest of the company. I get how it ended up in that spot. These days, I am a freelance developer experience consultant, and I spent a year-and-a-half at Glitch.com. And developer experience was always something that I really cared about. I did some work at GitHub that was about getting people—specifically teenagers living in public housing—into computing and the internet, and I'd had to do a bunch of DX work to make that happen because I had an afternoon to get people from zero to writing code.And that is not a straightforward situation, especially in a low-income housing environment, for example, right? So, I cared about this stuff a lot. And then I spent a year-and-a-half at Glitch.com, and it was like getting a graduate degree on everything about the leverage for creating outcomes in developer tools. And I just, I felt like I was carrying some gift from the Gods. I just, I felt the need to get this out to the wider world, and so that's what I do with Antigravity.Corey: When I got to catch up with you in person for the first time at the excellent and highly recommended Monktoberfest conference—Danilo: Excellent.Corey: —that the folks over at RedMonk put on every year, it was interesting, in that you and I got to talking very rapidly, not about technology as such, but about culture and the industry and values and the rest. It was a wonderfully refreshing conversation that I don't normally get to have so soon after meeting someone. I think that one of the more interesting aspects of our relatively wide-ranging conversation in a surprisingly brief period of time focused, first off, among the idea of developer tools and what so many of them seem to get wrong. I know that we basically dove into discussing about our violently agreeing opinions around the state of developer experience, for example. What are the hills you're willing to die on in that space?Danilo: I think that computing generally exists to amplify and multiply our power. Computing exists to let us do things that we could not do with the simple, frail flesh that we're born with, right? Computers augment our ambitions because they can do things with infinite iteration. And so, if you can come up with something that you can bottle in the form of an algorithm that repeats infinitely, you can have incredible impact on the world. And so, I think that there's a responsibility to find ways to make that power something that is easy to hand to other people and let them pick up and run with.And so, developer tools, to me, has this almost sacred connotation because what you're doing is handing people the fire of the Gods and saying, “Whatever you can come up with, whatever your imagination allows you to do with these tools, they can repeat infinitely and make whatever change you want—for good or for ill—in the world.” And that's very special to me. I think we've gotten bored of it because it's just, you know, it's a 50-year-old business at this point. But I think there's still a lot of magic to it, and the more we see the magic, the more magical outcomes we can coax out of everyday people who become better developers.Corey: From my perspective, one of the reasons I care so much about developer experience is that the failure mode of getting it wrong means that the person trying to understand the monstrosity you've built feels like they're somehow not smart, or they're just not getting it in some key and fundamental way. And that's not true. It's that you, for whatever reason, what you have built is not easily understandable to them where they are. I go back to what I first heard in 2012, at a talk that Logstash creator, Jordan Sissel wound up saying, where his entire thesis was that if a user has a bad time, it's a bug.Danilo: Yeah.Corey: And I thought that that was just a wonderfully prescient statement that I wanted to sign onto wholeheartedly. [That was 00:09:08] my first exposure to it. I know that's not the entirety of developer experience by a long shot, but it's the one where I think you lose the most mind share when you get it wrong.Danilo: Well, and I'm glad that you bring that up because I think that kind of defines the spectrum of the emotional experience of interacting with developer tools. On one end of the spectrum, you've got, “I feel so stupid. This has made me feel worse about myself. This has given me less of a sense of confidence in myself than I had when I started.” And at the other end of the spectrum, the other extreme is, “I cannot believe I am this cool. I cannot believe that my imagination has been made manifest in this way that now exists in the world and can go out and touch other people and make their lives better.”Those are the two, kind of, extremes of the subjective emotional experience that can come from developer tools. And so, I think that there is a business imperative that really pushes us toward the extreme of making people feel awesome. I think about this in the context of Iron Man, you've seen Iron Man, yeah.Corey: Oh, yes.Danilo: All right. So, the Iron Man suit is the perfect metaphor for a developer tool that is working correctly for you, right? Because on its own, the suit is not very interesting, and on his own, Tony Stark is not all that powerful, but you combine the suit and the person, and suddenly extraordinary emergent outcomes come out. The ambition of the human is amplified, and he feels so [BLEEP] cool. And I think that's what we're looking to do with developer tools is that we want to take a person, amplify their range, give them a range of motion that lets them soar into the clouds and do whatever they need to do up there so that when they come back down, they feel transformed. They feel like more than what they started.Corey: I would agree with that. There's a sense of whimsy and wonder as I look through my career trajectory, going from a sysadmin role, where you there was a pretty constant and hard to beat ratio in most shops—and the ratio [unintelligible 00:11:29] varied—but number of admins to the number of servers. And now with the magic of cloud being what it is, it's a, “Well, how many admins does it take to run X number of servers?” Like, “Well, as an [admin done 00:11:39] right, I can manage all of them because that's how programming languages work.” And that is a mystical and powerful thing.But lately, it seems like there's been some weird changes in the world of developer tooling. Cynically, I've said a couple of times that giving a toss about the developer experience was in fact a zero interest rate phenomenon. Like, when you're basically having to fend off casual offers of 400 grand a year from big tech, how do you hire and retain people at a company that has one of those old, tiny profit-generating business models and compete with them? And a lot of times, developer experience was part of how you did that. I don't know that I necessarily believe that that is as tied to that cynical worldview as I might pretend on the internet, but I don't know—I do wonder if it's a factor because it seems like we've seen a definite change in the way that developer tools are approaching their community of users and customers.Danilo: Well, my immediate reflex is to open up the kind of systems theory box and look at what's inside of that. Because I think that what we are experiencing, if we use the interest rate lens, is a period of time where everyone is a little bit worried that the good times are over for good. And I feel the sense of this in a lot of places. I think developer experience is a pretty good avatar to try this on with because I definitely also perceive it in that sphere.During the heyday of 0% interest rates, everything was about how much totalizing growth can you achieve? And from a developer tools perspective, all right, well, we need to make it so that the tools, kind of, grow themselves, so let's invest a lot in developer experience so that people very quickly get onboarded, without us having to hold their hand, without us having to conduct a sales call, let's get them to the point where they can quickly understand—because the documentation is so good and the artifacts are so good—exactly how to use these tools to maximum effect. Let's get them to a point where it's very easy for them to share the results of their work so that other people see the party and really want to join in. And so, all kinds of effort and energy and capital was being invested in this kind of growth strategy.And now I think that people are, again, a little bit afraid that the good times are over, and so we see this really sales-driven culture of growth, where it's like, all right, well, for this company to succeed, we have to really make sure that we're going and closing these big sales, and if individual developers can't figure out how the hell this works, well, that's their problem, and we're not going to worry about it. And we've talked about this: this fear of the good times being over drives people, I think, to all kinds of bad behavior. The rug-pulling that we've seen in open-source licensing where somebody's like, “All right, I've taken a bunch from this community, and now I'm going to keep it, and I'm not going to give anything back.” This is the behavior of people who are afraid that the good times are behind them. I don't have the luxury of being that pessimistic about the future, and I don't think our industry can afford it either.[midroll 00:15:03]Corey: The rules changing late in the game is something that has always upset me. It feels inherently unfair, and it's weird because you can have these companies say that, “Look, we've never done anything like that. Why wouldn't you trust us?” Right up until the point where they do. Reddit is a great example, where for years, they had a great API—ish—that could do things that their crap-ass mobile client natively couldn't. And Apollo was how I interacted with Reddit constantly. I was a huge Reddit user. I was simultaneously, at one point, moderator of the legal advice subreddit and the personal finance subreddit. I was passionate about that stuff, and it was great.And then they wound up effectively killing all third-party clients that don't bend the knee, and well, why am I going to spend my time donating content and energy and time to a for-profit company that gets very jealous when other people find ways to leverage their platform in ways that they don't personally find themselves able to do. Screw ‘em. I haven't been back on Reddit since. It's just a, “Fool me once, shame on me story.” Twitter did the exact same thing. I built a threading Twitter client simultaneously deployed to 20 AWS regions, until they decided they didn't want people creating content through their APIs and killed the whole thing with no notice. Great. Now, they're—I got an email asking me to come back. Go to hell. I tried that once. You've eviscerated people's businesses and the rest.And you see it with licensed changes as well. But it all comes down to the same thing, from my perspective, which is an after-the-fact changing of the rules. And by moving the goalposts like that, I wonder what guarantees a startup or a project that doesn't intend to do those things can offer to its community. Because, look, HashiCorp made its decision to change the licensing for Terraform. Good for them. They're entitled to do that. I'm not suggesting, in any way shape or form, that they have violated any legal term.And I don't even know they're necessarily doing anything that doesn't make sense from their point of view. And the only people I really see that upset about it are licensing purists—which I no longer am for a variety of reasons—people who work at HashiCorp, obviously, and their direct competitors who are not sympathetic in that particular place. But as a counterpoint, if they wind up building a new open-source project, of course, I'm not going to contribute. I mean, that's a decision I get to make. And I don't know how you square that circle because otherwise, if that continues, no one will be able to have a sense of safety around contributing to anything open-source unless they're pleased to wind up doing volunteer work for a one-day unicorn.Danilo: So, I really appreciate the economical survey of the landscape that you just provided because I think that captures it really well. The Reddit case in particular breaks my heart. I will go to my grave absolutely loving Steve Huffman. Steve Huffman gave me my first break as a paid developer and product designer, and he was an enormous pain in the ass to work with, and I loved every minute of it. Like, he's just an interesting, if volatile, character.And I see that volatility playing out with Red Hat in the incredible hostility that they were conveying around being held to account for these changes. And I have a lot of sympathy for that crew because they've built all this value, they kind of missed the euphoria boat in terms of, you know, getting the best price for an IPO, for example, and they've got to figure out, all right, how do we scrape together value from what we've got within the constraints that we have? How do we build a fence around the value that we've got and put a tollbooth in front of it so that the public markets are excited about this and give us our best bang for the buck? That's Steve Hoffman's job. That's his crew's job. I understand the pressures and I respect that.And I think that the way they went about it this year was short-sighted because what it does is it undervalues everybody who isn't in the boardroom, making decisions with them. I think what we have to understand that when we build software, Metcalfe's law applies to developer tools just as much as any other network here. And so, the people who are stakeholders, who are participants, who are constituents of your community, are load-bearing members of the value chain that you are putting together, and so when you just cut them out, you might be nicking an artery that bleeds out very, very, very slowly. And the sentiment that you just expressed here about how your experience of Reddit was soured, I mean you're the enthusiast type, right? Like, who wants to sign up for the drama of flame wars and moderation except if you really just love it?And so, what they were able to do was take people who, for years, absolutely loved it, and just drain away their love and enthusiasm for it. And the thing is, over time, that harms the long-term value that you are trying to actually protect. When we live in a world where computers can do all of this stuff infinitely, when they will provide us with extraordinary scale, when information can be copied and distributed at near-zero marginal cost, what we're doing is setting up chains of incentives to get people to do stuff, essentially, for free. You were unpaid labor doing that moderation, and the reason that you did it for free was because it was fun, was because it spoke to something inside of you that really mattered, and you wanted to provide for a community of other people who also cared about these topics. And that fun was taken away from you. So, there's a bunch of this stuff that doesn't fit into a spreadsheet, and if we make decisions exclusively on what fits into a spreadsheet, we're going to turn around someday and find that we have cut off some of the most valuable parts of what makes this industry great.Corey: I agree. I feel like companies have a—they launch, and they want the benefits of having an open-source community, but as they grow and get to a point of success and becoming self-sustaining, it's harder to see those benefits because at that point, it just feels like it's all downside: you are basically giving what you built away to your direct competitors, you are seeing significant value scattered throughout the ecosystem that you are capturing a very small portion of, and it becomes frustrating—especially in historical environments—where you have the sense of—back when you built the company years ago, it's well, obviously we'd be the best place to host and run this because no one's going to run this as well as the people who built it. And then cloud companies, with their operational excellence, come in and put the lie to that, in many cases [laugh]. It's like, oh dear. Not like that.And I understand, truly, the frustration and the pain and the fear that drives companies in that position. And I don't have a better answer, which is my big problem because I'm just sitting here saying, “You're doing it wrong. Don't do it like that.” “Okay, well, what should they do instead?” “No, I just want to be angry. I'm not here to offer solutions.” And I feel for them. I do. I have a lot of empathy for everyone involved in this conversation. It just sucks, but we need a better outcome than the current state, or we're going to not see the same open innovation. Even these days, when I build things, by default, I don't build in the open, not because I'm worried about competitive threats, but because I don't want to deal with people complaining to me about things that I've built and don't want to think about this week.Danilo: I think that we're living through the hangover of—I mean, if you looked at the crypto craze as an example of this hangover, right—here we were with the sky the limit. We can sell monkey pictures for extraordinary amounts of money and there's nothing behind it. We went from euphoria to fear in the space of a handful of quarters. And so, that has put all of us, even the most optimistic, in a place where we feel our backs are against the walls. But I think the responsibility we have is, again, computing fundamentally changes the economics of so many categories of labor, and it changes the economics of information generally.And so, we can do a bunch of stuff that doesn't cost that much over the long-term, relative to the value it creates. But it only works if we have a really clear thesis of the value we're creating. If we don't value the contributions of a community, if we don't value the emergent outcomes that arise from building something that's very expressive, that then lets outsiders show up and do things that we never predicted, if we're not building strategies that look at this value as something that is precious instead of something to be cut off and captured, then I think that we just continue to spiral down the drain of paranoia, and greed, and fear instead of doing things that actually create long-term sustainable growth for our business.Corey: I really wish that there were easier, direct paths. Like on some level, too, it's—I feel like this is part of the problem, that every company views going public as its ultimate goal.Danilo: Yeah.Corey: At least that's what it feels like. Like The Duckbill Group. If we ever go public, my God, I will have been so far gone from this company long before then, just because at that point, you have given control over to people who are not aligned, in many cases, with the values that you founded the company with. Like, one of the things I love about being a small business is that I don't need to necessarily think the next quarter's earnings. I can think longer-term. “Okay, in two or three years, what do I want to be doing?” Or five or ten. I'm not forced into this narrow, short-sighted treadmill where I have to continually show infinite growth in all areas at all times. That doesn't sound healthy.Danilo: I agree, and I think that this is a place where I can give you a lot of hope because I look at a handful of economic tailwinds that are really going to make it possible to build businesses in a different way than was practical before. If we look at the last cycle, one of the absolute game changers was open-source. So, you showed up and there was already a web server written for you, and there was already a database written for you, and so you would just pull these things off the shelf instead of having to hire a team that would build your web server from scratch, that would build your database from scratch. And so, that changed the economics of how companies could be made, and that created an entire cycle of new technology growth.And if we look for an analogy of that kind of labor savings for the next technology cycle, we're going to see things like cloud-based serverless services, right? So like, now you don't need to even administer a Linux server. You don't need to know how the server works under the hood. You pay one company for an API that gives you a database, and they manage the stuff. So, I'm thinking of companies like Neon, or PlanetScale, right? You give them cash, they give you a database, they worry about it, they do all of the on-call stuff, you don't have to think about. So, this makes it even cheaper to build things of higher complexity because you are outsourcing much of the management of that complexity to other firms. And I think that that pattern is going to change the overall costs of starting and scaling and maintaining any sort of web-based product. And so, that's number one.And then number two, is that when we look at stuff like large language models, the stuff that you can do with ChatGPT in terms of figuring out how to solve a broad array of problems that maybe you don't have a lot of domain expertise in, I think that means that we're going to see smaller teams get even further than we expect. And so, the net result of these trends is going to be, you don't need to take vast amounts of venture funding in order to get to a company that serves a large number of people at a meaningful scale, with meaningful returns for the principles involved, and then they don't have to go all the way down to the IPO route. They don't have to figure out some sort of mega-scale unicorn exit; they can just build companies that work, that solve customer problems, keep it close, and then you don't have the totalizing endless need for growth. I think we're going to see a lot more of that this cycle.Corey: I sure hope you're right. I think that there's been a clear trend toward panic, or at least if not panic, then at least looking at current conditions and assuming that they'll persist forever. We just saw ten years of an unprecedented bull run, where people tended to assume that interest rates would be forever low, growth was always going to be double-digit at least, and there was no need to think about anything that would ever argue against those things. For the first few years of my consulting company, it was a devil of a problem trying to convince people to care about their AWS bills because frankly, when money is free, there is no reason for someone to. They are being irrational if they do. Now, of course, that's a very different story, but at the time, I felt for a while like I was the one who was nuts.Danilo: So, the interest rate conditions are always going to make people behave a certain way. That's why they exist, right? We have monetary policy designed to influence business behavior. And if we look at that zoom, then we say, “All right, look, this stuff is all cyclical. We know there's going to be good times, we know there's going to be lean times, but at the end of the day, we care about building stuff.” Right?I don't spend a lot of time with the sort of venture capitalist set who's really obsessed with building, but I really love building. I just, I can't stop building things. It is what I was put on this planet to do, and I think that there are so many people who feel exactly the same way. And so, regardless of the larger interest-rate phenomenon, we have to find a path where we can just build the stuff that we need to build. Build it for our reasons, for the right reasons, not because we just want to cash out. Although, you know, getting paid is great. I don't begrudge anyone that.Corey: You can't eat aspirations, as it turns out.Danilo: That's right, right? We've got to worry about the economics, and that's reasonable. But at the end of the day, making things happen through technology is its own mission and its own reward, regardless of what some sort of venture fund needs to make return happen. So, I think that we are going to get past this moment of slump and return to the fundamentals of we need to build technology because building technology makes us feel good and creates impact in the world that we absolutely need. And those are the fundamentals of this business.Corey: I agree with you wholeheartedly. I think that I've been around too many cycles—this is a polite way of saying I'm old—and you learn when that happens that everything that feels so immediate and urgent in the moment, in the broad sweep of things, so rarely is. Not everything can be life or death because you'll die lots of times.Danilo: Yeah.Corey: I really want to thank you for taking the time to speak with me. If people want to learn more, where's the best place for them to find you?Danilo: If you want to engage me for my thinking and strategy around humanist technology tools growth, you should find me at antigravitydx.com. And if you want to read more about what I think about, I maintain a blog at redeem-tomorrow.com, and you can learn all about my thinking about the last cycle, and the coming one as well.Corey: And I will absolutely include a link to that in the [show notes 00:31:52]. Thank you so much for taking the time to speak with me. I appreciate it.Danilo: It's a pleasure, Corey. Thank you for having me. Really great to chat.Corey: Danilo Campos, proprietor at Antigravity DX. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment taking care within that comment to link to a particular section of the FutureAdvisor code repo.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.
This episode features a panel discussion with Stefano Maffulli, Executive Director of the Open Source Initiative (OSI); and Stephen O'Grady, Co-founder of RedMonk. Stefano has decades of experience in open source advocacy. He co-founded the Italian chapter of Free Software Foundation Europe, built the developer community of the OpenStack Foundation, and led open source marketing teams at several international companies. Stephen has been an industry analyst for several decades and is author of the developer playbook, The New Kingmakers: How Developers Conquered the World.In this episode, Sam, Stefano, and Stephen discuss the intersection of open source and AI, good data for everyone, and open data foundations.-------------------“Internet Archive, Wikipedia, they have that mission to accumulate data. The OpenStreetMap is another big one with a lot of interesting data. It's a fascinating space, though. There are so many facets of the word ‘data.' One of the reasons why open data is so hard to manage and hasn't had that same impact of open source is because, like Stephen, the stories that he was telling about the startups having a hard time assembling the mixing and matching, or modifying of data has a different connotation. It's completely different from being able to do the same with software.” – Stefano Maffulli“It's also not clear how said foundation would get buy-in. Because, as far as a lot of the model holders themselves, they've been able to do most of what they want already. What's the foundation really going to offer them? They've done what they wanted. Not having any inside information here, but just judging by the fact that they are willing to indemnify their users, they feel very confident legally in their stance. Therefore, it at least takes one of the major cards off the table for them.” – Stephen O'Grady-------------------Episode Timestamps:(01:44): What open source in the context of AI means to each guest(16:21): Stefano explains OSI's opportunity to shine a light on models and teams(21:22): The next step of open source AI according to Stephen(25:38): Creating better definitions in order to modify software(33:09): The case of funding an open data foundation(42:31): The future of open source data(51:54): Executive producer, Audra Montenegro's backstage takeaways-------------------Links:LinkedIn - Connect with StefanoVisit Open Source InitiativeLinkedIn - Connect with StephenVisit RedMonk
Peder Ulander, Chief Marketing & Strategy Officer at MongoDB, joins Corey on Screaming in the Cloud to discuss how MongoDB is paving the way for innovation. Corey and Peder discuss how Peder made the decision to go from working at Amazon to MongoDB, and Peder explains how MongoDB is seeking to differentiate itself by making it easier for developers to innovate without friction. Peder also describes why he feels databases are more ubiquitous than people realize, and what it truly takes to win the hearts and minds of developers. About Peder Peder Ulander, the maestro of marketing mayhem at MongoDB, juggles strategies like a tech wizard on caffeine. As the Chief Marketing & Strategy Officer, he battles buzzwords, slays jargon dragons, and tends to developers with a wink. From pioneering Amazon's cloud heyday as Director of Enterprise and Developer Solutions Marketing to leading the brand behind cloud.com's insurgency, Peder's built a legacy as the swashbuckler of software, leaving a trail of market disruptions one vibrant outfit at a time. Peder is the Scarlett Johansson of tech marketing — always looking forward, always picking the edgy roles that drive what's next in technology.Links Referenced:MongoDB: https://mongodb.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode of Screaming in the Cloud is brought to us by my friends and yours at MongoDB, and into my veritable verbal grist mill, they have sent Peder Ulander, their Chief Marketing Officer. Peder, an absolute pleasure to talk to you again.Peder: Always good to see you, Corey. Thanks for having me.Corey: So, once upon a time, you worked in marketing over at AWS, and then you transitioned off to Mongo to, again, work in marketing. Imagine that. Almost like there's a narrative arc to your career. A lot of things change when you change companies, but before we dive into things, I just want to call out that you're a bit of an aberration in that every single person that I have spoken to who has worked within your org has nothing but good things to say about you, which means you are incredibly effective at silencing dissent. Good work.Peder: Or it just shows that I'm a good marketer and make sure that we paint the right picture that the world needs to see.Corey: Exactly. “Do you have any proof of you being a great person to work for?” “No, just word of mouth,” and everyone, “Ah, that's how marketing works.”Peder: Exactly. See, I'm glad you picked up somewhere.Corey: So, let's dive into that a little bit. Why would you leave AWS to go work at Mongo. Again, my usual snark and sarcasm would come up with a half dozen different answers, each more offensive than the last. Let's be serious for a second. At AWS, there's an incredibly powerful engine that drives so much stuff, and the breadth is enormous.MongoDB, despite an increasingly broad catalog of offerings, is nowhere near that level of just universal applicability. Your product strategy is not a Post-It note with the word ‘yes' written on it. There are things that you do across the board, but they all revolve around databases.Peder: Yeah. So, going back prior to MongoDB, I think you know, at AWS, I was across a number of different things, from the developer ecosystem, to the enterprise transformation, to the open-source work, et cetera, et cetera. And being privy to how customers were adopting technology to change their business or change the experiences that they were delivering to their customers or increase the value of the applications that they built, you know, there was a common thread of something that fundamentally needed to change. And I like to go back to just the evolution of tech in that sense. We could talk about going from physical on-prem systems to now we're distributed in the cloud. You could talk about application constructs that started as big fat monolithic apps that moved to virtual, then microservices, and now functions.Or you think about networking, we've gone from fixed wire line, to network edge, and cellular, and what have you. All of the tech stack has changed with the exception of one layer, and that's the data layer. And I think for the last 20 years, what's been in place has worked okay, but we're now meeting this new level of scale, this new level of reach, where the old systems are not what's going to be what the new systems are built on, or the new experiences are built on. And as I was approached by MongoDB, I kind of sat back and said, “You know, I'm super happy at AWS. I love the learning, I love the people, I love the space I was in, but if I were to put my crystal ball together”—here's a Bezos statement of looking around corners—“The data space is probably one of the biggest spaces ripe for disruption and opportunity, and I think Mongo is in an incredible position to go take advantage of that.”Corey: I mean, there's an easy number of jokes to make about AmazonBasics MongoDB, which is my disparaging name for their DocumentDB first-party offering. And for a time, it really felt like AWS's perspective toward its partners was one of outright hostility, if not antagonism. But that narrative no longer holds true in 2023. There's been a definite shift. And to be direct, part of the reason that I believe that is the things you have said both personally and professionally in your role as CMO of Mongo that has caused me to reevaluate this because despite all of your faults—a counted list of which I can provide you after the show—Peder: [laugh].Corey: You do not say things that you do not believe to be true.Peder: Correct.Corey: So, something has changed. What is it?Peder: So, I think there's an element of coopetition, right? So, I would go as far as to say the media loved to sensationalize—actually even the venture community—loved to sensationalize the screen scraping stripping of open-source communities that Amazon represented a number of years ago. The reality was their intent was pretty simple. They built an incredibly amazing IT stack, and they wanted to run whatever applications and software were important to their customers. And when you think about that, the majority of systems today, people want to run open-source because it removes friction, it removes cost, it enables them to go do cool new things, and be on the bleeding edge of technology.And Amazon did their best to work with the top open-source projects in the world to make it available to their customers. Now, for the commercial vendors that are leaning into this space, that obviously does present itself threat, right? And we've seen that along a number of the cohorts of whether you want to call it single-vendor open-source or companies that have a heavy, vested interest in seeing the success of their enterprise stack match the success of the open-source stack. And that's, I think, where media, analysts, venture, all kind of jumped on the bandwagon of not really, kind of, painting that bigger picture for the future. I think today when I look at Amazon—and candidly, it'll be any of the hyperscalers; they all have a clone of our database—it's an entry point. They're running just the raw open-source operational database capabilities that we have in our community edition and making that available to customers.We believe there's a bigger value in going beyond just that database and introducing, you know, anything from the distributed zones to what we do around vector search to what we do around stream processing, and encryption and all of these advanced features and capabilities that enable our customers to scale rapidly on our platform. And the dependency on delivering that is with the hyperscalers, so that's where that coopetition comes in, and that becomes really important for us when we're casting our web to engage with some of the world's largest customers out there. But interestingly enough, we become a big drag of services for an AWS or any of the other hyperscalers out there, meaning that for every dollar that goes to a MongoDB, there's, you know, three, five, ten dollars that goes to these hyperscalers. And so, they're very active in working with us to ensure that, you know, we have fair and competing offers in the marketplace, that they're promoting us through their own marketplace as well as their own channels, and that we're working together to further the success of our customers.Corey: When you take a look at the exciting things that are happening at the data layer—because you mentioned that we haven't really seen significant innovation in that space for a while—one of the things that I see happening is with the rise of Generative AI, which requires very special math that can only be handled by very special types of computers. I'm seeing at least a temporary inversion in what has traditionally been thought of as data gravity, whereas it's easier to move compute close to the data, but in this case, since the compute only lives in the, um, sparkling us-east-1 regions of Virginia, otherwise, it's just generic, sparkling expensive computers, great, you have to effectively move the mountain to Mohammed, so to speak. So, in that context, what else is happening that is driving innovation in the data space right now?Peder: Yeah, yeah. I love your analogy of, move the mountain of Mohammed because that's actually how we look at the opportunity in the whole Generative AI movement. There are a lot of tools and capabilities out there, whether we're looking at code generation tools, LLM modeling vendors, some of the other vector database companies that are out there, and they're all built on the premise of, bring your data to my tool. And I actually think that's a flawed strategy. I think that these are things that are going to be features in core application databases or operational databases, and it's going to be dependent on the reach and breadth of that database, and the integrations with all of these AI tools that will define the victor going forward.And I think that's been a big core part of our platform. When we look at Atlas—111 availability zones across all three hyperscalers with a single, unified, you know, interface—we're actually able to have the customers keep their operational data where it's most important to them and then apply the tools of the hyperscalers or the partners where it makes the most sense without moving the data, right? So, you don't actually have to move the mountain to Mohammed. We're literally building an experience where those that are running on MongoDB and have been running on MongoDB can gain advantage of these new tools and capabilities instantly, without having to change anything in their architectures or how they're building their applications.Corey: There was a somewhat over-excited… I guess, over-focus in the space of vector databases because whatever those are—which involves math, and I am in no way shape, or form smart enough to grasp the nuances thereof, but everyone assures me that it's necessary for Generative AI and machine learning and yadda, yadda, yadda. So, when in doubt, when I'm confronted by things I don't fully understand, I turn to people who do. And the almost universal consensus that I have picked up from people who track databases for a living—as opposed to my own role of inappropriately using everything in the world except databases as a database—is that vector is very much a feature, not a core database type.Peder: Correct. The best way to think about it—I mean, databases in general, they're dealing with structured and unstructured data, and generally, especially when you're doing searches or relevance, you're limited to the fact that those things in the rows and the columns or in the documents is text, right? And the reality is, there's a whole host of information that can be found in metadata, in images, in sounds, in all of these other sources that were stored as individual files but unsearchable. Vector, vectorization, and vector embeddings actually enable you to take things far beyond the text and numbers that you traditionally were searching against and actually apply more, kind of, intelligence to it, or apply sounds or apply sme—you know, you can vectorize smells to some extent. And what that does is it actually creates a more pleasing slash relevant experience for how you're actually building the engagements with your customers.Now, I'll make it a little more simple because that was trying to define vectors, which as you know, is not the easiest thing. But imagine being able to vectorize—let's say I'm a car company—we're actually working with a car company on this—and you're able to store all of the audio files of cars that are showing certain diagnostic issues—the putters and the spurts and the pings and the pangs—and you can actually now isolate these sounds and apply them directly to the problem and resolution for the mechanics that are working on them. Using all of this stuff together, now you actually have a faster time to resolution. You don't want mechanics knowing the mechanics of vectors in that sense, right, so you build an application that abstracts all of that complexity. You don't require them to go through PDFs of data and find all of the options for fixing this stuff.The relevance comes back and says, “Yes, we've seen that sound 20 times across this vehicle. Here's how you fix it.” Right? And that cuts significant amount of time, cost, efficiency, and complexity for those auto mechanics. That is such a big push forward, I think, from a technology perspective, on what the true promise of some of these new capabilities are, and why I get excited about what we're doing with vector and how we're enabling our customers to, you know, kind of recreate experiences in a way that are more human, more relevant.Corey: Now, I have to say that of course you're going to say nice things about your capabilities where vector is concerned. You would be failing in your job if you did not. So, I feel like I can safely discount every positive thing that you say about Mongo's positioning in the vector space and instead turn to, you know, third parties with no formalized relationship with you. Yesterday, Retool's State of AI report came across my desk. I am a very happy Retool customer. They've been a periodic sponsor, from time-to-time, of my ridiculous nonsense, which is neither here nor there, but I want to disclaim the relationship.And they had a Gartner Magic Quadrant equivalent that on one axis had Net Promoter Score—NPS, which is one of your people's kinds of things—and the other was popularity. And Mongo was so far up and to the right that it was almost hilarious compared to every other entrant in the space. That is a positioning that I do not believe it is possible to market your way into directly. This is something that people who are actually doing these things have to use the product, and it has to stand up. Mongo is clearly effective at doing this in a way that other entrants aren't. Why?Peder: Yeah, that's a good question. I think a big part of that goes back to the earlier statement I made that vector databases or vector technology, it's a feature, it's not a separate thing, right? And when I think about all of the new entrants, they're creating a new model where now you have to move your data out of your operational database and into their tool to get an answer and then push back in. The complexity, the integrations, the capabilities, it just slows everything down, right? And I think when you look at MongoDB's approach to take this developer data platform vision of getting all of the core tools that developers need to build compelling applications with from a data perspective, integrating it into one seamless experience, we're able to basically bring classic operational database capabilities, classic text search type capabilities, embed the vector search capabilities as well, it actually creates a richer platform and experience without all of that complexity that's associated with bolt-on sidecar Gen AI tool or vector database.Corey: I would say that that's one of those things that, again, can only really be credibly proven by what the market actually does, as opposed to, you know, lip-sticking the heck out of a pig and hoping that people don't dig too deeply into what you're saying. It's definitely something we're seeing adoption of.Peder: Yeah, I mean, this kind of goes to some of the stuff, you know, you pointed out, the Retool thing. This is not something you can market your way into. This is something that, you know, users are going to dictate the winners in this space, the developers, they're going to dictate the winners in the space. And so, what do you have to do to win the hearts and minds of developers, you have to make the tech extremely approachable, it's got to be scalable to meet their needs, not a lot of friction involved in learning these new capabilities and applying it to all of the stuff that has come before. All of these things put together, really focusing on that developer experience, I mean, that goes to the core of the MongoDB ethos.I mean, this is who we were when we started the company so long ago, and it's continued to drive the innovation that we do in the platform. And I think this is just yet again, another example of focusing on developer needs, making it super engaging and useful, removing the friction, and enabling them to just go create new things. That's what makes it so fun. And so when, you know, as a marketer, and I get the Retool chart across my desk, we haven't been pitching them, we haven't been marketing to them, we haven't tried to influence this stuff, so knowing that this is a true, unbiased audience, actually is pretty cool to see. To your point, it was surprising how far up and to the right that we sat, given, you know, where we were in just—we launched this thing… six months ago? We launched it in June. The amount of customers that have signed up, are using it, and engaged with us on moving forward has been absolutely amazing.Corey: I think that there has been so much that gets lost in the noise of marketing. My approach has always been to cut through so much of it—that I think AWS has always done very well with—is—almost at their detriment these days—but if you get on stage, you can say whatever you want about your company's product, and I will, naturally and lovingly, make fun of whatever it is that you say. But when you have a customer coming on stage and saying, “This is how we are using the thing that they have built to solve a very specific business problem that was causing us pain,” then I shut up, and I listen because it's very hard to wind up dismissing that without being an outright jerk about things. I think the failure mode of that is, taken too far, you lose the ability to tell your own story in a coherent way, and it becomes a crutch that becomes very hard to get rid of. But the proof is really in the pudding.For me, like, the old jokes about—in the early teens—where MongoDB would periodically lose data as configured by default. Like, “MongoDB. It's Snapchat for databases.” Hilarious joke at the time, but it really has worn thin. That's like being angry about what Microsoft did in 2005 and 2006. It's like, “Yeah, okay, you have a point, but it is also ancient history, and at some point you need to get with the modern era, get with the program.”And I think that seeing the success and breadth of MongoDB that I do—you are in virtually every customer that I talk to, in some way, shape, or form—and seeing what it is that they're doing with you folks, it is clear that you are not a passing fad, that you are not going away anytime soon.Peder: Right.Corey: And even with building things in my spare time and following various tutorials of dubious credibility from various parts of the internet—as those things tend to go—MongoDB is very often a default go-to reference when someone needs a database for which a SQLite file won't do.Peder: Right. It's fascinating to see the evolution of MongoDB, and today we're lucky to track 45,000-plus customers on our platform doing absolutely incredible things. But I think the biggest—to your point—the biggest proof is in the pudding when you get these customers to stand up on stage and talk about it. And even just recently, through our .local series, some of the customers that we've been highlighting are doing some amazing things using MongoDB in extremely business-critical situations.My favorite was, I was out doing our .local in Hong Kong, where Cathay Pacific got up on stage, and they talked a little bit about their flight folder. Now, if you remember going through the airport, you always see the captains come through, and they had those two big boxes of paperwork before they got onto the plane. Not only was that killing the environment with all the trees that got cut down for it, it was cumbersome, complex, and added a lot of time and friction with regards to flight operations. Now, take that from a single flight over all of the fleet that's happening across the world.We were able to work with Cathay Pacific to digitize their entire flight folder, all of their documentation, removing the need for cutting down trees and minimizing a carbon footprint form, but at the same time, actually delivering a solution where if it goes down, it grounds the entire fleet of the airline. So, imagine that. That's so business-critical, mission-critical, has to be there, reliable, resilient, available for the pilots, or it shuts down the business. Seeing that growth and that transformation while also seeing the environmental benefit for what they have achieved, to me, that makes me proud to work here.Similarly, we have companies like Ford, another big brand-name company here in the States, where their entire connected car experience and how they're basically operationalizing the connection between the car and their home base, this is all being done using MongoDB as well. So, as they think of these new ideas, recognizing that things are going to be either out at the edges or at a level of scale that you can't just bring it back into classic rows and columns, that's actually where we're so well-suited to grow our footprint. And, you know, I remember back to when I was at Sun—Sun Microsystems. I don't know if anybody remembers that company. That was an old one.But at one point, it was Jonathan that said, “Everything of value connects to the network.” Right? Those things that are connecting to the network also need applications, they need data, they need all of these services. And the further out they go, the more you need a database that basically scales to meet them where they are, versus trying to get them to come back to where your database happens to sit. And in order to do that, that's where you break the mold.That's where—I mean, that kind of goes into the core ethos of why we built this company to begin with. The original founders were not here to build a database; they were building a consumer app that needed to scale to the edges of the earth. They recognized that databases didn't solve for that, so they built MongoDB. That's actually thinking ahead. Everything connecting to the network, everything being distributed, everything basically scaling out to all the citizens of the planet fundamentally needs a new data layer, and that's where I think we've come in and succeeded exceptionally well.Corey: I would agree. Another example I like to come up with, and it's fun that the one that leaps to the top of my mind is not one of the ones that you mentioned, but HSBC—the massive bank—very publicly a few years ago, wound up consolidating, I think it was 46 relational databases onto MongoDB. And the jokes at the time wrote themselves, but let's be serious for a second. Despite the jokes that we all love to tell, they are a bank, a massive bank, and they don't play fast-and-loose or slap-and-tickle with transactional integrity or their data stores for these things.Because there's a definite belief across the banking sector—and I know this having worked in it myself for years—that if at some point, you have the ATMs spitting out the wrong account balances, people will begin rioting in the streets. I don't know if that's strictly accurate or hyperbole, but it's going to cause massive amounts of chaos if it happens. So, that is something that absolutely cannot happen. The fact that they're willing to engage with you folks and your technology and be public about it at that scale, that's really all you need to know from a, “Is this serious technology or clown shoes technology?”Peder: [laugh]. Well, taking that comment, now let's exponentially increase that. You know, if I sit back, and I look at my customer base, financial services is actually one of our biggest verticals as a business. And you mentioned HSBC. We had Wells Fargo on the stage last year at our world event.Nine out of the top ten world's banks are using MongoDB in some of their applications, some at the scale of HSBC, some are still just getting started. And it all comes down to the fact that we have proven ourselves, we are aligned to mission-critical business environments. And I think when it comes down to banks, especially that transactional side, you know, building in the capabilities to be able to have high frequency transactions in the banking world is a hard thing to go do, and we've been able to prove it with some of the largest banks on the planet.Corey: I also want to give you credit—although it might be that I'm giving you credit for a slow release process; I hope not—but when I visit mongodb.com, it still talks up front that you are—and I want to quote here—oh, good lord, it changes every time I load the page—but it talks about, “Build faster, build smarter,” on this particular version of the load. It talks about the data platform. You have not effectively decided to pivot everything you say in public to tie directly into the Generative AI hype bubble that we are currently experiencing. You have a bunch of different use cases, and you're not suddenly describing what you do in Gen AI terms that make it impossible to understand just what the company-slash-product-slash-services actually do.Peder: Right.Corey: So, I want to congratulate you on that.Peder: Appreciate that, right? Look, it comes down to the core basics. We are a developer data platform. We bring together all of the capabilities, tools, and functions that developers need when building apps as it pertains to their data functions or data layer, right? And that's why this integrated approach of taking our operational database and building in search, or stream processing, or vector search, all of the things that we're bringing to the platform enable developers to move faster. And what that says is, we're great for all use cases out there, not just Gen AI use cases. We're great for all use cases where customers are building applications to change the way that they're engaging with the customers.Corey: And what I like about this is that you're clearly integrating this stuff under the hood. You are talking to people who are building fascinating stuff, you're building things yourself, but you're not wrapping yourself in the mantle of, “This is exactly what we do because it's trendy right now.” And I appreciate that. It's still intelligible, and I wouldn't think that I had to congratulate someone on, “Wow, you build marketing that a human being can extract meaning from. That's amazing.” But in 2023, the closing days thereof, it very much is.Peder: Yep, yep. And it speaks a lot to the technology that we've built because, you know, on one side—it reminds me a lot of the early days of cloud where everything was kind of cloud-washed for a bit, we're seeing a little bit of that in the hype cycle that we have right now—sticking to our guns and making sure that we are building a technology platform that enables developers to move quickly, that removing the friction from the developer lifecycle as it pertains to the data layer, that's where the success is right, we have to stay on top of all of the trends, we have to make sure that we're enabling Gen AI, we have to make sure that we're integrating with the Amazon Bedrocks and the CodeWhisperers of the world, right, to go push this stuff forward. But to the point we made earlier, those are capabilities and features of a platform where the higher-level order is to really empower our customers to develop innovative, disruptive, or market-leading technologies for how they engage with their customers.Corey: Yeah. And that it's neat to be able to see that you are empowering companies to do that without feeling the need to basically claim their achievements as your own, which is an honest-to-God hard thing to do, especially as you become a platform company because increasingly, you are the plumbing that makes a lot of the flashy, interesting stuff possible. It's imperative, you can't have those things without the underlying infrastructure, but it's hard to talk about that infrastructure, too.Peder: You know, it's funny, I'm sure all of my colleagues would hate me for saying this, but the wheel doesn't turn without the ball bearing. Somebody still has to build the ball bearing in order for that sucker to move, right? And that's the thing. This is the infrastructure, this is the heart of everything that businesses need to build applications. And one of the—you know, another kind of snide comment I've made to some of my colleagues here is, if you think about every market-leading app, in fact, let's go to the biggest experiences you and I use on a daily basis, I'm pretty sure you're booking travel online, you're searching for stuff on Google, you're buying stuff through Amazon, you're renting a house through Airbnb, and you're listening to your music through Spotify. What are those? Those are databases with a search engine.Corey: The world is full of CRUD applications. These are, effectively, simply pretty front-ends to a database. And as much as we'd like to pretend otherwise, that's very much the reality of it. And we want that to be the case. Different modes of interaction, different requirements around them, but yeah, that is what so much of the world is. And I think to ignore that is to honestly blind yourself to a bunch of very key realities here.Peder: That kind of goes back to the original vision for when I came here. It's like, look, everything of value for us, everything that I engage with, is—to your point—it's a database with a great experience on top of it. Now, let's start to layer in this whole Gen AI push, right, what's going on there. We're talking about increased relevance in search, we're talking about new ways of thinking about sourcing information. We've even seen that with some of the latest ChatGPT stuff that developers are using that to get code snippets and figure out how to solve things within their platform.The era of the classic search engine is in the middle of a complete change, and the opportunity, I think, that I see as this moves forward is that there is no incumbent. There isn't somebody who owns this space, so we're just at the beginning of what probably will be the next. Google's, Airbnb's, and Uber's of the world for the next generation. And that's really exciting to see.Corey: I'm right there with you. What are the interesting founding stories at Google is that they wound up calling typical storage vendors for what they needed, got basically ‘screw on out of here, kids,' pricing, so they shrugged, and because they had no real choice to get enterprise-quality hardware, they built a bunch of highly redundant systems on top of basically a bunch of decommissioned crap boxes from the university they were able to more or less get for free or damn near it, and that led to a whole innovation in technology. One of the glorious things about cloud that I think goes under-sold is that I can build a ridiculous application tonight for maybe, what, 27 cents IT infrastructure spend, and if it doesn't work, I round up to dollar, it'll probably get waived because it'll cost more to process the credit card transaction than take my 27 cents. Conversely, if it works, I'm already building with quote-unquote, “Enterprise-grade” components. I don't need to do a massive uplift. I can keep going. And that is no small thing.Peder: No, it's not. When you step back, every single one of those stories was about abstracting that complexity to the end-user. In Google's case, they built their own systems. You or I probably didn't know that they were screwing these things together and soldering them in the back room in the middle of the night. Similarly, when Amazon got started, that was about taking something that was only accessible to a few thousand and now making it accessible to a few million with the costs of 27 cents to build an app.You removed the risk, you removed the friction from enabling a developer to be able to build. That next wave—and this is why I think the things we're doing around Gen AI, and our vector search capabilities, and literally how we're building our developer data platform is about removing that friction and limits and enabling developers to just come in and, you know, effectively do what they do best, which is innovate, versus all of the other things. You know, in the Google world, it's no longer racking and stacking. In the cloud world, it's no longer managing and integrating all the systems. Well, in the data world, it's about making sure that all of those integrations are ready to go and at your fingertips, and you just focus on what you do well, which is creating those new experiences for customers.Corey: So, we're recording this a little bit beforehand, but not by much. You are going to be at re:Invent this year—as am I—for eight nights—Peder: Yes.Corey: Because for me at least, it is crappy cloud Hanukkah, and I've got to deal with that. What have you got coming up? What do you plan to announce? Anything fun, exciting, or are you just there basically, to see how many badges you can actually scan in one day?Peder: Yeah [laugh]. Well, you know, it's shaping up to be quite an incredible week, there's no question. We'll see what brings to town. As you know, re:Invent is a huge event for us. We do a lot within that ecosystem, a lot of the customers that are up on stage talking about the cool things they're doing with AWS, they're also MongoDB customers. So, we go all out. I think you and I spoke before about our position there with SugarCane right on the show floor, I think we've managed to secure you a Friends of Peder all-access pass to SugarCane. So, I look forward to seeing you there, Corey.Corey: Proving my old thesis of, it really is who you know. And thank you for your generosity, please continue.Peder: [laugh]. So, we will be there in full force. We have a number of different innovation talks, we have a bunch of community-related events, working with developers, helping them understand how we play in the space. We're also doing a bunch of hands-on labs and design reviews that help customers basically build better, and build faster, build smarter—to your point earlier on some of the marketing you're getting off of our website. But we're also doing a number of announcements.I think first off, it was actually this last week, we made the announcement of our integrations with Amazon—or—yeah, Amazon CodeWhisperer. So, their code generation tool for developers has now been fully trained on MongoDB so that you can take advantage of some of these code generation tools with MongoDB Atlas on AWS. Similarly, there's been a lot of noise around what Amazon is doing with Bedrock and the ability to automate certain tasks and things for developers. We are going to be announcing our integrations with Agents for Amazon Bedrock being supported inside of MongoDB Atlas, so we're excited to see that, kind of, move forward. And then ultimately, we're really there to celebrate our customers and connect them so that they can share what they're doing with many peers and others in the space to give them that inspiration that you so eloquently talked about, which is, don't market your stuff; let your customers tell what they're able to do with your stuff, and that'll set you up for success in the future.Corey: I'm looking forward to seeing what you announce in conjunction with what AWS announces, and the interplay between those two. As always, I'm going to basically ignore 90% of what both companies say and talk instead to customers, and, “What are you doing with it?” Because that's the only way to get truth out of it. And, frankly, I've been paying increasing amounts of attention to MongoDB over the past few years, just because of what people I trust who are actually good at databases have to say about you folks. Like, my friends at RedMonk always like to say—I've stolen the line from them—“You can buy my attention, but not my opinion.”Peder: A hundred percent.Corey: You've earned the opinion that you have, at this point. Thank you for your sponsorship; it doesn't hurt, but again, you don't get to buy endorsements. I like what you're doing. Please keep going.Peder: No, I appreciate that, Corey. You've always been supportive, and definitely appreciate the opportunity to come on Screaming in the Cloud again. And I'll just push back to that Friends of Peder. There's, you know, also a little bit of ulterior motive there. It's not just who you know, but it's [crosstalk 00:34:39]—Corey: It's also validating that you have friends. I get it. I get it.Peder: Oh yeah, I know, right? And I don't have many, but I have a few. But the interesting thing there is we're going to be able to connect you with a number of the customers doing some of these cool things on top of MongoDB Atlas.Corey: I look forward to it. Thank you so much for your time. Peder Ulander, Chief Marketing Officer at MongoDB. I'm Cloud Economist Corey Quinn and this has been a promoted guest episode of Screaming in the Cloud, brought to us by our friends at Mongo. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review in your podcast platform of choice, along with an angry, insulting comment that I will ignore because you basically wrapped it so tightly in Generative AI messaging that I don't know what the hell your point is supposed to be.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.
Randall Degges, Head of Developer Relations & Community at Snyk, joins Corey on Screaming in the Cloud to discuss Snyk's innovative AI strategy and why developers don't need to be afraid of security. Randall explains the difference between Large Language Models and Symbolic AI, and how combining those two approaches creates more accurate security tooling. Corey and Randall also discuss the FUD phenomenon to selling security tools, and Randall expands on why Snyk doesn't take that approach. Randall also shares some background on how he went from being a happy Snyk user to a full-time Snyk employee. About RandallRandall runs Developer Relations & Community at Snyk, where he works on security research, development, and education. In his spare time, Randall writes articles and gives talks advocating for security best practices. Randall also builds and contributes to various open-source security tools.Randall's realms of expertise include Python, JavaScript, and Go development, web security, cryptography, and infrastructure security. Randall has been writing software for over 20 years and has built a number of popular API services and open-source tools.Links Referenced: Snyk: https://snyk.io/ Snyk blog: https://snyk.io/blog/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn, and this featured guest episode is brought to us by our friends at Snyk. Also brought to us by our friends at Snyk is one of our friends at Snyk, specifically Randall Degges, their Head of Developer Relations and Community. Randall, thank you for joining me.Randall: Hey, what's up, Corey? Yeah, thanks for having me on the show, man. Looking forward to talking about some fun security stuff today.Corey: It's been a while since I got to really talk about a security-centric thing on this show, at least in order of recordings. I don't know if the one right before this is a security thing; things happen on the back-end that I'm blissfully unaware of. But it seems the theme lately has been a lot around generative AI, so I'm going to start off by basically putting you in the hot seat. Because when you pull up a company's website these days, the odds are terrific that they're going to have completely repositioned absolutely everything that they do in the context of generative AI. It's like, “We're a generative AI company.” It's like, “That's great.” Historically, I have been a paying customer of Snyk so that it does security stuff, so if you're now a generative AI company, who do I use for the security platform thing that I was depending upon? You have not done that. First, good work. Secondly, why haven't you done that?Randall: Great question. Also, you said a moment ago that LLMs are very interesting, or there's a lot of hype around it. Understatement of the last year, for sure [laugh].Corey: Oh, my God, it has gotten brutal.Randall: I don't know how many billions of dollars have been dumped into LLM in the last 12 months, but I'm sure it's a very high number.Corey: I have a sneaking suspicion that the largest models cost at least a billion each train, just based upon—at least retail price—based upon the simple economics of how long it takes to do these things, how expensive that particular flavor of compute is. And the technology is his magic. It is magic in a box and I see that, but finding ways that it applies in different ways is taking some time. But that's not stopping the hype beasts. A lot of the same terrible people who were relentlessly pushing crypto have now pivoted to relentlessly pushing generative AI, presumably because they're working through Nvidia's street team, or their referral program, or whatever it is. Doesn't matter what the rest of us do, as long as we're burning GPU cycles on it. And I want to distance myself from that exciting level of boosterism. But it's also magic.Randall: Yeah [laugh]. Well, let's just talk about AI insecurity for a moment and answer your previous question. So, what's happening in space, what's the deal, what is all the hype going to, and what is Snyk doing around there? So, quite frankly—and I'm sure a lot of people on your show say the same thing—but Snyk isn't new into, like, the AI space. It's been a fundamental part of our platform for many years now.So, for those of you listening who have no idea what the heck Snyk is, and you're like, “Why are we talking about this,” Snyk is essentially a developer security company, and the core of what we do is two things. The first thing is we help scan your code, your dependencies, your containers, all the different parts of your application, and detect vulnerabilities. That's the first part. The second thing we do is we help fix those vulnerabilities. So, detection and remediation. Those are the two components of any good security tool or security company.And in our particular case, we're very focused on developers because our whole product is really based on your application and your application security, not infrastructure and other things like this. So, with that being said, what are we doing at a high level with LLMs? Well, if you think about AI as, like, a broad spectrum, you have a lot of different technologies behind the scenes that people refer to as AI. You have lots of these large language models, which are generating text based on inputs. You also have symbolic AI, which has been around for a very long time and which is very domain specific. It's like creating specific rules and helping do pattern detection amongst things.And those two different types of applied AI, let's say—we have large language models and symbolic AI—are the two main things that have been happening in industry for the last, you know, tens of years, really, with LLM as being the new kid on the block. So, when we're talking about security, what's important to know about just those two underlying technologies? Well, the first thing is that large language models, as I'm sure everyone listening to this knows, are really good at predicting things based on a big training set of data. That's why companies like OpenAI and their ChatGPT tool have become so popular because they've gone out and crawled vast portions of the internet, downloaded tons of data, classified it, and then trained their models on top of this data so that they can help predict the things that people are putting into chat. And that's why they're so interesting, and powerful, and there's all these cool use cases popping up with them.However, the downside of LLMs is because they're just using a bunch of training data behind the scenes, there's a ton of room for things to be wrong. Training datasets aren't perfect, they're coming from a ton of places, and even if they weren't perfect, there's still the likelihood that things that are going to be generating output based on a statistical model isn't going to be accurate, which is the whole concept of hallucinations.Corey: Right. I wound up remarking on the livestream for GitHub Universe a week or two ago that the S in AI stood for security. One of the problems I've seen with it is that it can generate a very plausible looking IAM policy if you ask it to, but it doesn't actually do what you think it would if you go ahead and actually use it. I think that it's still squarely in the realm of, it's great at creativity, it's great at surface level knowledge, but for anything important, you really want someone who knows what they're doing to take a look at it and say, “Slow your roll there, Hasty Pudding.”Randall: A hundred percent. And when we're talking about LLMs, I mean, you're right. Security isn't really what they're designed to do, first of all [laugh]. Like, they're designed to predict things based on statistics, which is not a security concept. But secondly, another important thing to note is, when you're talking about using LLMs in general, there's so many tricks and techniques and things you can do to improve accuracy and improve things, like for example, having a ton of [contexts 00:06:35] or doing Few-Shot Learning Techniques where you prompt it and give it examples of questions and answers that you're looking for can give you a slight competitive edge there in terms of reducing hallucinations and false information.But fundamentally, LLMs will always have a problem with hallucinations and getting things wrong. So, that brings us to what we mentioned before: symbolic AI and what the differences are there. Well, symbolic AI is a completely different approach. You're not taking huge training sets and using machine learning to build statistical models. It's very different. You're creating rules, and you're parsing very specific domain information to generate things that are highly accurate, although those models will fail when applied to general-purpose things, unlike large language models.So, what does that mean? You have these two different types of AI that people are using. You have symbolic AI, which is very specific and requires a lot of expertise to create, then you have LLMs, which take a lot of experience to create as well, but are very broad and general purpose and have a capability to be wrong. Snyk's approach is, we take both of those concepts, and we use them together to get the best of both worlds. And we can talk a little bit about that, but I think fundamentally, one of the things that separates Snyk from a lot of other companies in the space is we're just trying to do whatever the best technical solution is to solve the problem, and I think we found that with our hybrid approach.Corey: I think that there is a reasonable distrust of AI when it comes to security. I mean, I wound up recently using it to build what has been announced by the time this thing airs, which is my re:Invent photo scavenger hunt app. I know nothing about front-end, so that's okay, I've got a robot in my pocket. It's great at doing the development of the initial thing, and then you have issues, and you want to add functionality, and it feels like by the time I was done with my first draft, that ten different engineers had all collaborated on this thing without ever speaking to one another. There was no consistent idiomatic style, it used a variety, a hodgepodge of different lists and the rest, and it became a bit of a Frankenstein's monster.That can kind of work if we're talking about a web app that doesn't have any sensitive data in it, but holy crap, the idea of applying that to, “Yeah, that's how we built our bank's security policy,” is one of those, “Let me know who said that, so they can not have their job anymore,” territory when the CSO starts [hunting 00:08:55].Randall: You're right. It's a very tenuous situation to be in from a security perspective. The way I like to think about it—because I've been a developer for a long time and a security professional—and I as much as anyone out there love to jump on the hype train for things and do whatever I can to be lazy and just get work done quicker. And so, I use ChatGPT, I use GitHub Copilot, I use all sorts of LLM-based tools to help me write software. And similarly to the problems when developers are not using LLM to help them write code, security is always a concern.Like, it doesn't matter if you have a developer writing every line of code themselves or if they're getting help from Copilot or ChatGPT. Fundamentally, the problem with security and the reason why it's such an annoying part of the developer experience, in all honesty, is that security is really difficult. You can take someone who's an amazing engineer, who has 30 years of experience, like, you can take John Carmack, I'm sure, one of the most legendary developers to ever walk the Earth, you could sit over his shoulder and watch him write software, right, I can almost guarantee you that he's going to have some sort of security problem in his code, even with all the knowledge he has in his head. And part of the reason that's the case is because modern security is way complicated. Like if you're building a web app, you have front-end stuff you need to protect, you have back-end stuff you need to protect, there's databases and infrastructure and communication layers between the infrastructure and the services. It's just too complicated for one person to fully grasp.And so, what do you do? Well, you basically need some sort of assistance from automation. You have to have some sort of tooling that can take a look at your code that you're writing and say, “Hey Randall, on line 39, when you were writing this function that's taking user data and doing something with it, you forgot to sanitize the user data.” Now, that's a simple example, but let's talk about a more complex example. Maybe you're building some authentication software, and you're taking users' passwords, and you're hashing them using a common hashing algorithm.And maybe the tooling is able to detect way using the bcrypt password hashing algorithm with a work factor of ten to create this password hash, but guess what, we're in 2023 and a work factor of ten is something that older commodity CPUs can now factor at a reasonable rate, and so you need to bump that up to 13 or 14. These are the types of things where you need help over time. It's not something that anyone can reasonably assume they can just deal with in their head. The way I like to think about it is, as a developer, regardless of how you're building code, you need some sort of security checks on there to just help you be productive, in all honesty. Like, if you're not doing that, you're just asking for problems.Corey: Oh, yeah. On some level, even the idea of it's just going to be very computationally expensive to wind up figuring out what that password hash is, well great, but one of the things that we've been aware of for a while is that given the rise of botnets and compromised computers, the attackers have what amounts to infinite computing capacity, give or take. So, if they want in, on some level, badly enough, they're going to find a way to get in there. When you say that every developer is going to sit down and write insecure code, you're right. And a big part of that is because, as imagined today, security is an incredibly high friction process, and it's not helped, frankly, by tools that don't have nuance or understanding.If I want to do a crap ton of busy work that doesn't feel like it moves the needle forward at all, I'll go around to resolving the hundreds upon hundreds of Dependabot alerts I have for a lot of my internal services that write my weekly newsletter. Because some dependency three deep winds up having a failure mode when it gets untrusted input of the following type, it can cause resource exhaustion. It runs in a Lambda function, so I don't care about the resources, and two, I'm not here providing the stuff that I write, which is the input with an idea toward exploiting stuff. So, it's busy work, things I don't need to be aware of. But more to the point, stuff like that has the high propensity to mask things I actually do care about. Getting the signal from noise from your misconfigured, ill-conceived alerting system is just awful. Like, a bad thing is there are no security things for you to work on, but a worse one is, “Here are 70,000 security things for you to work on.” How do you triage? How do you think about it?Randall: A hundred percent. I mean, that's actually the most difficult thing, I would say, that security teams have to deal with in the real world. It's not having a tool to help detect issues or trying to get people to fix them. The real issue is, there's always security problems, like you said, right? Like, if you take a look and just scan any codebase out there, any reasonably-sized codebase, you're going to find a ridiculous amount of issues.Some of those issues will be actual issues, like, you're not doing something in code hygiene that you need to do to protect stuff. A lot of those issues are meaningless things, like you said. You have a transitive dependency that some direct dependency is referring to, and maybe in some function call, there's an issue there, and it's alerting you on it even though you don't even use this function call. You're not even touching this class, or this method, or whatever it is. And it wastes a lot of time.And that's why the Holy Grail in the security industry in all honesty is prioritization and insights. At Snyk, we sort of pioneered this concept of ASPM, which stands for Application Security Posture Management. And fundamentally what that means is when you're a security team, and you're scanning code and finding all these issues, how do you prioritize them? Well, there's a couple of approaches. One approach is to use static analysis to try to figure out if these issues that are being detected are reachable, right? Like, can they be achieved in some way, but that's really hard to do statically and there's so many variables that go into it that no one really has foolproof solutions there.The second thing you can do is you can combine insights and heuristics from a lot of different places. So, you can take a look at static code analysis results, and you can combine them with agents running live that are observing your application, and then you can try to determine what stuff is actually reachable given this real world heuristic, and you know, real time information and mapping it up with static code analysis results. And that's really the holy grail of figuring things out. We have an ASPM product—or maybe it's a feature, an offering, if you will, but it's something that Snyk provides, which gives security admins a lot more insight into that type of operation at their business. But you're totally right, Corey, it's a really difficult problem to solve, and it burns a lot of goodwill in the security community and in the industry because people spend a lot of time getting false alerts, going through stuff, and just wasting millions of hours a year, I'm sure.Corey: That's part of the challenge, too, is that it feels like there are two classes of problems in the world, at least when it comes to business. And I found this by being on the wrong side of it, on some level. Here on the wrong side, it's things like caring about cost optimization, it's caring about security, it's remembering to buy fire insurance for your building. You can wind up doing all of those things—and you should be doing them, but you can over-index on them to the point where you run out of money and your business dies. The proactive side of that fence is getting features to market sooner, increasing market share, growing revenue, et cetera, and that's the stuff that people are always going to prioritize over the back burner stuff. So, striking a balance between that is always going to be a bit of a challenge, and where people land on that is going to be tricky.Randall: So, I think this is a really good bridge. You're totally right. It's expensive to waste people's time, basically, is what you're saying, right? You don't want to waste people's time, you want to give them actionable alerts that they can actually fix, or hopefully you fix it for them if you can, right? So, I'm going to lay something out, which is, in our opinion, is the Snyk way, if you will, that you should be approaching these developer security issues.So, let's take a look at two different approaches. The first approach is going to be using an LLM, like, let's say, just ChatGPT. We'll call them out because everyone knows ChatGPT. The first approach we're going to take is—Corey: Although I do insist on pronouncing it Chat-Gippity. But please, continue.Randall: [laugh]. Chat-Gippity. I love that. I haven't heard that before. Chat-Gippity. Sounds so much more fun, you know?Corey: It sounds more personable. Yeah.Randall: Yeah. So, you're talking to Chat-Gippity—thank you—and you paste in a file from your codebase, and you say, “Hey, Chat-Gippity. Here's a file from my codebase. Please help me identify security issues in here,” and you get back a long list of recommendations.Corey: Well, it does more than that. Let me just interject there because one of the things it does that I think very few security engineers have mastered is it does it politely and constructively, as opposed to having an unstated tone of, “You dumbass,” which I beli—I've [unintelligible 00:17:24] with prompts on this. You can get it to have a condescending, passive-aggressive tone, but you have to go out of your way to do it, as opposed to it being the default. Please continue.Randall: Great point. Also, Daniel from Unsupervised Learning, by the way, has a really good post where he shows you setting up Chat-Gippity to mimic Scarlett Johansson from the movie Her on your phone so you can talk to it. Absolutely beautiful. And you get these really fun, very nice responses back and forth around your code analysis. So, shout out there.But going back to the point. So, if you get these responses back from Chat-Gippity, and it's like, “Hey look, here's all the security issues,” a lot of those things will be false alerts, and there's been a lot of public security research done on these analysis tools just give you information. A lot of those things will be false alerts, some things will be things that maybe they're a real problem, but cannot be fixed due to transitive dependencies, or whatever the issues are, but there's a lot of things you need to do there. Now, let's take it up one notch, let's say instead of using Chat-Gippity directly, you're using GitHub Copilot. Now, this is a much better situation for working with code because now what Microsoft is doing is let's say you're running Copilot inside of VS Code. It's able to analyze all the files in your codebase, and it's able to use that additional context to help provide you with better information.So, you can talk to GitHub Copilot and say, “Hey, I'd really like to know what security issues are in this file,” and it's going to give you maybe a little bit better answers than ChatGPT directly because it has more context about the other parts of your codebase and can give you slightly better answers. However, because these things are LLMs, you're still going to run into issues with accuracy, and hallucinations, and all sorts of other problems. So, what is the better approach? And I think that's fundamentally what people want to know. Like, what is a good approach here?And on the scanning side, the right approach in my mind is using something very domain specific. Now, what we do at Snyk is we have a symbolic AI scanning engine. So, we take customers' code, and we take an entire codebase so you have access to all the files and dependencies and things like this, and you take a look at these things. And we have a security analyst team that analyzes real-world security issues and fixes that have been validated. So, we do this by pulling lots of open-source projects as well as other security information that we originally produced, and we define very specific rules so that we can take a look at software, and we can take a look at these codebases with a very high degree of certainty.And we can give you a very actionable list of security issues that you need to address, and not only that, we can show you how is going to be the best way to address them. So, with that being said, I think the second side to that is okay, if that's a better approach on the scanning side, maybe you shouldn't be using LLMs for finding issues; maybe you should be using them for fixing security issues, which makes a lot of sense. So, let's say you do it the Snyk way, and you use symbolic AI engines and you sort of find these issues. Maybe you can just take that information then, in combination with your codebase, and fire off a request to an LLM and say, “Hey Chat-Gippity, please take this codebase, and take this security information that we know is accurate, and fix this code for me.” So, now you're going one step further.Corey: One challenge that I've seen, especially as I've been building weird software projects with the help of magic robots from the future, is that a lot of components, like in React for example, get broken out into their own file. And pasting a file in is all well and good, but very often, it needs insight into the rest of the codebase. At GitHub Universe, something that they announced was Copilot Enterprise, which trains Copilot on the intricacies of your internal structures around shared libraries, all of your code, et cetera. And in some of the companies I'm familiar with, I really believe that's giving a very expensive, smart robot a form of brain damage, but that's neither here nor there. But there's an idea of seeing the interplay between different components that individual analysis on a per-file basis will miss, feels to me like something that needs a more holistic view. Am I wrong on that? Am I oversimplifying?Randall: You're right. There's two things we need to address. First of all, let's say you have the entire application context—so all the files, right—and then you ask an LLM to create a fix for you. This is something we do at Snyk. We actually use LLMs for this purpose. So, we take this information we ask the LLM, “Hey, please rewrite this section of code that we know has an issue given this security information to remove this problem.” The problem then becomes okay, well, how do you know this fix is accurate and is not going to break people's stuff?And that's where symbolic AI becomes useful again. Because again, what is the use case for symbolic AI? It's taking very specific domains of things that you've created very specific rule sets for and using them to validate things or to pass arbitrary checks and things like that. And it's a perfect use case for this. So, what we actually do with our auto-fix product, so if you're using VS Code and you have Copilot, right, and Copilot's spitting out software, as long as you have Snyk in the IDE, too, we're actually taking a look at those lines of code Copilot just inserted, and a lot of the time, we are helping you rewrite that code to be secured using our LLM stuff, but then as soon as we get that fixed created, we actually run it through our symbolic engine, and if we're saying no, it's actually not fixed, then we go back to the LLM, we re-prompt it over and over again until we get a working solution.And that's essentially how we create a much more sophisticated iteration, if you will, of using AI to really help improve code quality. But all that being said, you still had a good point, which is maybe if you're using the context from the application, and people aren't doing things properly, how does that impact what LLMs are generating for you? And an interesting thing to note is that our security team internally here, just conducted a really interesting project, and I would be angry at myself if I didn't explain it because I think it's a very cool concept.Corey: Oh, please, I'm a big fan of hearing what people get up to with these things in ways that is real-world stories, not trying to sell me anything, or also not dunking on, look what I saw on the top of Hacker News the other day, which is, “If all you're building is something that talks to Chat-Gippity's API, does some custom prompting, and returns a response, you shouldn't be building it.” I'm like, “Well, I built some things that do exactly that.” But I'm also not trying to raise $6 million in seed money to go and productize it. I'm just hoping someone does it better eventually, but I want to use it today. Please tell me a real world story about something that you've done.Randall: Okay. So, here's what we did. We went out and we found a bunch of GitHub projects, and we tried to analyze them ourselves using a bunch of different tools, including human verification, and basically give it a grade and say, “Okay, this project here has really good security hygiene. Like, there's not a lot of issues in the code, things are written in a nice way, the style and formatting is consistent, the dependencies are up-to-date, et cetera.” Then we take a look at multiple GitHub repos that are the opposite of that, right? Like, maybe projects that hadn't been maintained in a long time, or were written in a completely different style where you have bad hygienic practices, maybe you have hard-coded secrets, maybe you have unsanitized input coming from a user or something, right, but you take all these things.So, we have these known examples of good and bad projects. So, what did we do? Well, we opened them up in VS Code, and we basically got GitHub Copilot and we said, “Okay, what we're going to do is use each of these codebases, and we're going to try to add features into the projects one at a time.” And what we did is we took a look at the suggested output that Copilot was giving us in each of these cases. And the interesting thing is that—and I think this is super important to understand about LLMs, right—but the interesting thing is, if we were adding features to a project that has good security hygiene, the types of code that we're able to get out of LLMs, like, GitHub Copilot was pretty good. There weren't a ton of issues with it. Like, the actual security hygiene was, like, fairly good.However, for projects where there were existing issues, it was the opposite. Like we'd get AI recommendations showing us how to write things insecurely, or potentially write things with hard-coded secrets in it. And this is something that's very reproducible today in, you know, what is it right now, middle of November 2023. Now, is it going to be this case a year from now? I don't necessarily know, but right now, this is still a massive problem, so that really reinforces the idea that not only when you're talking about LLMs is the training set they used to build the model's important, but also the context in which you're using them is incredibly important.It's very easy to mislead LLMs. Another example of this, if you think about the security scanning concept we talked about earlier, imagine you're talking to Chat-Gippity, and you're [pasting 00:25:58] in a Python function, and the Python function is called, “Completely_safe_not_vulnerable_function.” That's the function name. And inside of that function, you're backdooring some software. Well, if you ask Chat-Gippity multiple times and say, “Hey, the temperature is set to 1.0. Is this code safe?”Sometimes you'll get the answer yes because the context within the request that has that thing saying this is not a vulnerable function or whatever you want to call it, that can mislead the LLM output and result in problems, you know? It's just, like, classic prompt injection type issues. But there's a lot of these types of vulnerabilities still hidden in plain sight that impact all of us, and so it's so important to know that you can't just rely on one thing, you have to have multiple layers: something that helps you with things, but also something that is helping you fix things when needed.Corey: I think that's the key that gets missed a lot is the idea of it's not just what's here, what have you put here that shouldn't be; what have you forgotten? There's a different side of it. It's easy to do a static analysis and say, “Oh, you're not sanitizing your input on this particular form.” Great. Okay—well, I say it's easy. I wish more people would do that—but then there's also a step beyond of, what is it that someone who has expertise who's been down this road before would take one look at your codebase and say, “Are you making this particular misconfiguration or common misstep?”Randall: Yeah, it's incredibly important. You know, like I said, security is just one of those things where it's really broad. I've been working in security for a very long time and I make security mistakes all the time myself.Corey: Yeah. Like, in your developer environment right now, you ran this against the production environment and didn't get permissions errors. That is suspicious. Tell me more about your authentication pattern.Randall: Right. I mean, there's just a ton of issues that can cause problems. And it's… yeah, it is what it is, right? Like, software security is something difficult to achieve. If it wasn't difficult, everyone would be doing it. Now, if you want to talk about, like, vision for the future, actually, I think there's some really interesting things with the direction I see things going.Like, a lot of people have been leaning into the whole AI autonomous agents thing over the last year. People started out by taking LLMs and saying, “Okay, I can get it to spit out code, I can get it to spit out this and that.” But then you go one step further and say, “All right, can I get it to write code for me and execute that code?” And OpenAI, to their credit, has done a really good job advancing some of the capabilities here, as well as a lot of open-source frameworks. You have Langchain, and Baby AGI, and AutoGPT, and all these different things that make this more feasible to give AI access to actually do real meaningful things.And I can absolutely imagine a world in the future—maybe it's a couple of years from now—where you have developers writing software, and it could be a real developer, it could be an autonomous agent, whatever it is. And then you also have agents that are taking a look at your software and rewriting it to solve security issues. And I think when people talk about autonomous agents, a lot of the time they're purely focusing on LLMs. I think it's a big mistake. I think one of the most important things you can do is focus on the very niche symbolic AI engines that are going to be needed to guarantee accuracy with these things.And that's why I think the Snyk approach is really cool, you know? We dedicated a huge amount of resources to security analysts building these very in-depth rule sets that are guaranteeing accuracy on results. And I think that's something that the industry is going to shift towards more in the future as LLMs become more popular, which is, “Hey, you have all these great tools, doing all sorts of cool stuff. Now, let's clean it up and make it accurate.” And I think that's where we're headed in the next couple of years.Corey: I really hope you're right. I think it's exciting times, but I also am leery when companies go too far into boosterism where, “Robots are going to do all of these things for us.” Maybe, but even if you're right, you sound psychotic. And that's something that I think gets missed in an awful lot of the marketing that is so breathless with anticipation. I have to congratulate you folks on not getting that draped over your message, once again.My other favorite part of your messaging when you pull up snyk.com—sorry, snyk.io. What is it these days? It's the dot io, isn't it?Randall: Dot io. It's hot.Corey: Dot io, yes.Randall: Still hot, you know?Corey: I feel like I'm turning into a boomer here where, “The internet is dot com.”Randall: [laugh].Corey: Doesn't necessarily work that way. But no, what I love is the part where you have this fear-based marketing of if you wind up not using our product, here are all the terrible things that will happen. And my favorite part about that marketing is it doesn't freaking exist. It is such a refreshing departure from so much of the security industry, where it does the fear, uncertainty, and doubt nonsense stuff that I love that you don't even hint in that direction. My actual favorite thing that is on your page, of course, is at the bottom. If you mouse over the dog in the logo at the bottom of the page, it does the quizzical tilting head thing, and I just think that is spectacular.Randall: So, the Snyk mascot, his name is Pat. He's a Doberman and everyone loves him. But yeah, you're totally right. The FUD thing is a real issue in security. Fear, uncertainty, and doubt, it's the way security companies sell products to people. And I think it's a real shame, you know?I give a lot of tech talks, at programming conferences in particular, around security and cryptography, and one of the things I always start out with when I'm giving a tech talk about any sort of security or cryptography topic is I say, “Okay, how many of you have landed in a Stack Overflow thread where you're talking about a security topic and someone replies and says, ‘oh, a professional should be doing this. You shouldn't be doing it yourself?'” That comes up all the time when you're looking at security topics on the internet. Then I ask people, “How many of you feel like security is this, sort of like, obscure, mystical arts that requires a lot of expertise in math knowledge, and all this stuff?” And a lot of people sort of have that impression.The reality though is security, and to some extent, cryptography, it's just like any other part of computer science. It's something that you can learn. There's best practices. It's not rocket science, you know? Maybe it is if you're developing a brand-new hashing algorithm from scratch, yes, leave that to the professionals. But using these things is something everyone needs to understand well, and there's tons of material out there explaining how to do things right. And you don't need to be afraid of this stuff, right?And so, I think, a big part of the Snyk message is, we just want to help developers just make their code better. And what is one way that you're going to do a better job at work, get more of your code through the PR review process? What is a way you're going to get more features out? A big part of that is just building things right from the start. And so, that's really our focus in our message is, “Hey developers, we want to be, like, a trusted partner to help you build things faster and better.” [laugh].Corey: It's nice to see it, just because there's so much that just doesn't work out the way that we otherwise hope it would. And historically, there's been a tremendous problem of differentiation in the security space. I often remark that at RSA, there's about 12 companies exhibiting. Now sure, there are hundreds of booths, but it's basically the same 12 things. There's, you know, the entire row of firewalls where they use different logos and different marketing words on the slides, but they're all selling fundamentally the same thing. One of things I've always appreciated about Snyk is it has never felt that way.Randall: Well, thanks. Yeah, we appreciate that. I mean, our whole focus is just developer security. What can we do to help developers build things securely?Corey: I mean, you are sponsoring this episode, let's be clear, but also, we are paying customers of you folks, and that is not—those things are not related in any way. What's the line that we like to use that we stole from the RedMonk folks? “You can buy our attention, but not our opinion.” And our opinion of what you folks are up to is then stratospherically high for a long time.Randall: Well, I certainly appreciate that as a Snyk employee who is also a happy user of the service. The way I actually ended up working at Snyk was, I'd been using the product for my open-source projects for years, and I legitimately really liked it and I thought this was cool. And yeah, I eventually ended up working here because there was a position, and you know, a friend reached out to me and stuff. But I am a genuinely happy user and just like the goal and the mission. Like, we want to make developers' lives better, and so it's super important.Corey: I really want to thank you for taking the time to speak with me about all this. If people want to learn more, where's the best place for them to go?Randall: Yeah, thanks for having me. If you want to learn more about AI or just developer security in general, go to snyk.io. That's S-N-Y-K—in case it's not clear—dot io. In particular, I would actually go check out our [Snyk Learn 00:34:16] platform, which is linked to from our main site. We have tons of free security lessons on there, showing you all sorts of really cool things. If you check out our blog, my team and I in particular also do a ton of writing on there about a lot of these bleeding-edge topics, and so if you want to keep up with cool research in the security space like this, just check it out, give it a read. Subscribe to the RSS feed if you want to. It's fun.Corey: And we will put links to that in the [show notes 00:34:39]. Thanks once again for your support, and of course, putting up with my slings and arrows.Randall: And thanks for having me on, and thanks for using Snyk, too. We love you [laugh].Corey: Randall Degges, Head of Developer Relations and Community at Snyk. This featured guest episode has been brought to us by our friends at Snyk, and I'm Corey Quinn. If you've enjoyed this episode, please leave a five-star review on your podcast platform of choice, whereas if you've hated this episode, please leave a five-star review on your podcast platform of choice, along with an angry comment that I will get to reading immediately. You can get me to read it even faster if you make sure your username is set to ‘Dependabot.'Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.
Jeremy Tangren, Director of Media Operations at The Duckbill Group, joins Corey on Screaming in the Cloud to discuss how he went from being a Project Manager in IT to running Media Operations at a cloud costs consultancy. Jeremy provides insight into how his background as a Project Manager has helped him tackle everything that's necessary in a media production environment, as well as what it was like to shift from a career on the IT side to working at a company that is purely cloud-focused. Corey and Jeremy also discuss the coordination of large events like re:Invent, and what attendance is really like when you're producing the highlight reels that other people get to watch from the comfort of their own homes. About JeremyWith over 15 years of experience in big tech, Jeremy brings a unique perspective to The Duckbill Group and its Media Team. Jeremy handles all things Media Operations. From organizing the team and projects to making sure publications go out on time, Jeremy does a bit of everything!Links Referenced: duckbillgroup.com: https://duckbillgroup.com requinnvent.com: https://requinnvent.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's guest is one of those behind-the-scenes type of people who generally doesn't emerge much into the public eye. Now, that's a weird thing to say about most folks, except in this case, I know for a fact that it's true because that's kind of how his job was designed. Jeremy Tangren is the Director of Media Operations here at The Duckbill Group. Jeremy, thank you for letting me drag you into the spotlight.Jeremy: Of course. I'm happy to be here, Corey.Corey: So, you've been here, what, it feels like we're coming up on the two-year mark or pretty close to it. I know that I had you on as a contractor to assist with a re:Invent a couple years back and it went so well, it's, “How do we get you in here full time? Oh, we can hire you.” And the rest sort of snowballed from there.Jeremy: Yes. January will be two years, in fact.Corey: I think that it's one of the hardest things to do for you professionally has always been to articulate the value that you bring because I've been working with you here for two years and I still do a pretty poor job of doing it, other than to say, once you get brought into a project, all of the weird things that cause a disjoint or friction along the way or cause the wheels to fall off magically go away. But I still struggle to articulate what that is in a context that doesn't just make it sound like I'm pumping up my buddy, so to speak. How do you define what it is that you do? I mean, now Director of Media Operations is one of those titles that can cover an awful lot of ground, and because of a small company, it obviously does. But how do you frame what you do?Jeremy: Well, I am a professional hat juggler, for starters. There are many moving parts and I come from a history of project management, a long, long history of project management. And I've worked with projects from small scale to the large scale spanning globally and I always understand that there are many moving parts that have to be tracked and handled, and there are many people involved in that process. And that's what I bring here to The Duckbill Group is that experience of managing the small details while also understanding the larger picture.Corey: It's one of those hard-to-nail-down type of roles. It's sort of one of those glue positions where, in isolation, it's well, there's not a whole lot that gets done when it is just you. I felt the same thing my entire career as a sysadmin turned other things that are basically fancy titles but still distilled down to systems administrator. And that is, well step one, I need a web property or some site or something that is going to absorb significant traffic and have developers building it. Because, “Oh, I'm going to run some servers.” “Okay, for what purpose?” “I don't know.”I was never good at coming up with the application that rode on top of these things. But give me someone else's application, I could make it scale and a bunch of exciting ways, back when that was trickier to do at smaller scale. These days, the providers out there make it a heck of a lot easier and all I really wind up doing is—these days—making fun of other people's hard work. It keeps things simpler, somehow.Jeremy: There always has to be a voice leading that development and understanding what you're trying to achieve at the end. And that's what a project manager, or in my role as Director of Media Operations, that's what I do is I see our vision to the end and I bring in the people and resources necessary to make it happen.Corey: Your background is kind of interesting. You have done a lot of things that a lot of places, mostly large companies, and mostly on the corporate IT side of the world. But to my understanding, this is the first time you've really gone into anything approaching significant depth with things that are cloud-oriented. What's it been like for you?Jeremy: It's a new experience. As you said, I've had experience all over the industry. I come from traditional data centers and networking. I'm originally trained in Cisco networking from way back in the day, and then I moved on into virtual reality development and other infrastructure management. But getting into the cloud has been something new and it's been a shift from old-school data centers in a way that is complicated to wrap your head around.Whereas in a data center before, it was really clear you had shelves of hardware, you had your racks, you had your disks, you had finite resources, and this is what you did; you built your applications on top of it and that was the end of the conversation. Now, the application is the primary part of the conversation, and scaling is third, fourth, fifth in the conversation. It's barely even mentioned because obviously we're going to put this in the cloud and obviously we're going to scale this out. And that's a power and capability that I had not seen in past companies, past infrastructures. And so, learning about the cloud, learning about the numerous AWS [laugh] services that exist and how they interact, has been a can of worms to understand and slowly take one worm out at a time and work with it and become its friend.Corey: I was recently reminded of a time before cloud where I got to go hang out with the founders at Oxide over in Oakland. I'd forgotten so much of the painful day-to-day minutia of what it took to get servers up and running in a data center, of the cabling nonsense, of slicing your fingers to ribbons on rack nuts, on waiting weeks on end for the server you ordered to show up, ideally in the right configuration, of getting 12 servers and 11 of them provision correctly and the 12th doesn't for whatever godforsaken reason. So, much of that had just sort of slipped my mind. And, “Oh, yeah, that's right. That's what the whole magic of cloud was.”Conversely, I've done a fair bit of IoT stuff at home for the past year or so, just out of basically looking for a hobby, and it feels different, for whatever reason, to be running something that I'm not paying a third party by the hour for. The actual money that we're talking about in either case is nothing, but there's a difference psychologically and I'm wondering how much the current cloud story is really shaping the way that an entire generation is viewing computers.Jeremy: I would believe that it is completely shifted how we view computers. If you know internet and computing history, we're kind of traveling back to the old ways of the centrally managed server and a bunch of nodes hanging off of it, and they basically being dummy nodes that access that central resource. And so, with the centralization of AWS resources and kind of a lot of the internet there, we've turned everyone into just a node that accesses this centralized resource. And with more and more applications moving to the web, like, natively the web, it's changing the need for compute on the consumer side in such a way that we've never seen, ever. We have gone from a standard two-and-a-half, three-foot tall tower sitting in your living room, and this is the family computer to everybody has their own personal computer to everyone has their own laptops to now, people are moving away from even those pieces of hardware to iPads because all of the resources that they use exist on the internet. So, now you get the youngest generation that's growing up and the only thing that they've ever known as far as computers go is an iPad in their hands. When I talk about a tower, what does that mean to them?Corey: It's kind of weird, but I feel like we went through a generation where it felt like the early days of automobiles, where you needed to be pretty close to a mechanic in order to reliably be convinced you could take a car any meaningful distance. And then they became appliances again. And in some cases, because manufacturers don't want people working on cars, you also have to be more or less a hacker of sorts to wind up getting access to your car. I think, on some level, that we've seen computers turn into appliances like that. When I was a kid, I was one of those kids that was deep into computers and would help the teachers get their overhead projector-style thing working and whatnot.And I think we might be backing away from that, on some level, just because it's not necessary to have that level of insight into how a system works to use it effectively. And I'm not trying to hold back the tide of progress. I just find it interesting as far as how we are relating with these things differently. It's a rising tide that absolutely lifts all ships, and that's a positive thing.Jeremy: Well, to carry your analogy further with cars, it used to be, especially in the United States, that in order to drive a car you had to understand a manual transmission, how to shift through all those gears, which gave you some understanding of what a clutch was and how the car moved. You had a basic understanding of how the car functions. And now in the United States, we all have automatic transmissions, and if I ask a regular person, “Do you understand how an engine works?” They'll just tell me straight, “No, I have no idea. My car gets me from A to B.”And computers have very much become that way, especially with this iPad generation that we're talking about, where it's a tool to access resources to get you from A to B, to get you from your fingertips to whatever the tools are that you're trying to access that are probably on the internet. And it changes the focus of what you need to learn as you're growing up and as you get into the industry. Because, say, for me, and you, Corey, we grew up with computers in their infancy and being those kids in the classroom, helping the teachers, helping our family members with whatever tech problem that they may have. Those were us. And we had to learn a lot about the technology and we had to learn a lot of troubleshooting skills in order to fix our family's problems, to help the classroom teacher, whatever it was. So, that's the set of skills that we learned through that generation of computers that the current generation isn't having to deal with as far as the complexity and the systems are concerned. So, they're able to learn different skills. They're able to interact with things more natively than you were I ever imagined.Corey: Well, I'm curious to get your perspective on how that's changed in the ways that you're interacting with teams from a project management perspective. I mean, obviously, we've seen a lot of technological advancement over the course of your career, which is basically the same length as mine, but what have you seen as far as how that affects the interplay of people on various teams? Or has it?Jeremy: It's made them more connected and less connected at the same time. I've found my most effective teams—generally—worked together in the same location and could turn around and poke the other team member in the back. And that facilitated communication all of the time. But that's not how every team can function. You have to lay on project management, you have to lay on tools and communication. And that's where this technology comes in is, how has it improved? How has it changed things?And interestingly, the web has advanced that, I think, to a significant degree because the old school, old project management style was either we're going to start planning this in Excel like so many managers do, or we're going to open up Microsoft Project and we're going to spend hours and hours and hours in this interface that only the project manager can access and show everyone. So, now we're in a point where everybody can access the project plan because it exists on the web—Smartsheets or whatever—we have instant communication via chat—whatever our chat of choice is Slack, Discord, IRC—and it allows us to work anywhere and be asynchronous. So, this team that previously I had to have sitting next to each other to poke each other, they can now be spread all over the world. I had a project a number of years ago working in virtual reality that we did exactly that. We had six teams spanned globally, and because we were able to hand off from each other through technology and through competent project management, the project was able to be built and successful rather than us continuing to point fingers at each other trying to understand what the next step is. So yeah, the technology has definitely helped.Corey: It's wild to me just seeing how… I guess, the techno-optimism has always been, “Oh, technology will heal the world and make things better,” as if it were this panacea that was going to magically take care of everything. And it's sort of a “Mo money, mo problems” type of situation where we've got, okay, great. Well, we found ways to make the old things that were super hard trivial, and all that's done is unlock a new level of problem because people remain people, for whatever it is. You work a lot more with people than you do with technology, despite the fact that if you look at the actual ins and outs of what you do, it's easy to look at that and say, “Oh, clearly, you're a technical person working on technology.” I would say you're a people-facing person.Jeremy: I agree with that, and that's why I refer to the people participating in my projects or on my team or what have you as people and not resources. Because people contribute to these things, not resources.Corey: So, what I'm curious about—since everyone seems to have a very disjointed opinion or perspective on how the sausage gets made over here—can you describe what your job is because I've talked to people who are surprised I have someone running media operations. Like, “How hard is it? You just sit down in front of a microphone and talk, and that's the end of it.” And I don't actually know the answer to that question because all I do is sit down in front of a microphone and talk, and that's the end of it. You have put process around things that used to vex me mightily and now I don't really know exist. So, it's sort of a weird question, but what is it you'd say it is you do exactly?Jeremy: I've actually had to answer this question a lot of times. The really, really simple version is I do everything that Corey doesn't [laugh]. Corey records and creates the content, he's the face of the company—you are the face of the company, Corey—and you do what you do. And that leaves everything else that has to be done. Okay, you record an episode of Screaming in the Cloud. What happens next?Well, it goes off to a team to be edited and then reviewed by the recording guest—to be reviewed by the guest. We have video editing that has to take place every time you go out to a shoot, we coordinate your presence on-site at events, we coordinate the arrival of other people to your events. In its shortest form, everything that is media-related that entails some kind of management or execution that is not creating content, I'm there moving things along or I have one of my teams moving things along.Corey: Before you showed up, there were times where I would record episodes like this and they wouldn't get published for three or four months because I would forget to copy the files from the recording off so that the audio processing team could handle that. And small minor process improvements have meant that I'm no longer the critical path for an awful lot of things, which is awesome. It's one of those invisible things around me that I vaguely know is there most of the time, but don't stop to think about it in quite the same way. Like, think of it as taking an airline trip somewhere: you get on the plane, you talk to the person at the gate, you [unintelligible 00:17:05] the flight attendants help you with your beverages or bags and whatnot, but you don't think about all the other moving parts that has to happen around aircraft maintenance, around scheduling, around logistics, around making sure that the seat is clean before you sit down at cetera, et cetera. There's so much stuff that you're sort of aware of you stopped to think about it, but it's not something that you see on a day-to-day basis, and as a result, it's easy to forget that it's there.Jeremy: That's what happens with people working in the background and making sure that things happen. A good example of this is also re:Quinnvent coming up here in a month, where we'll be at re:Invent—my production team, Corey, et cetera—where Corey will be recording content and we will be producing it in very short order. And this is an operation that has to occur without Corey's involvement. These are things that happen in the background in order to produce the content for the audience. There's always somebody who exists behind the scenes to move things along behind the creator. Because, Corey, you're a very busy person.Corey: People forget that I also have this whole, you know, consulting side thing that I do, too—Jeremy: Yeah.Corey: You know, the primary purpose of our company?Jeremy: Yeah. You are one of the busiest people I've ever met, Corey. Your calendar is constantly full and you're constantly speaking to people. There's no way that you would have the time to go in and edit each of these audio recordings, each of these video recordings, what have you. You have to have force multipliers hiding behind you to make things happen. And that's the job of the Director of Media Operations at Last Week in AWS.Corey: I have to ask since last year was your first exposure to it—that was your first re:Invent in person—what do you think of it?Jeremy: It was a madhouse [laugh]. I had managed re:Quinnvent back in 2021 remotely and I did not have the clear understanding of how far away things are, how convoluted the casinos are, things of that nature. And so, when I was working with you in 2021, Corey, I had to make a lot of assumptions that now I know better now that I've been on site. Like, it can take you 30 or 45 minutes to get across the street to one of the other re:Invent locations. It's really ridiculous.Corey: That was one of the reasons I had you and also I had Mike go out to re:Invent in person the first year that I was working with either of you on a full-time basis, just because otherwise it turned into, “Oh, it's just across the street. Just pop on over and say hi. It'll take you 20 minutes.” No, it'll take 90 by the time you walk through the casinos, find your way out, get over there, have your meeting, and get back. It's not one of those things that's trivial, but it's impossible to describe without sounding like a lunatic until someone has actually been there before.Jeremy: That's absolutely true. The personal experience is absolutely required in order to understand the scale of the situation, the number of people that are there, and the amount of time it's going to take to get to wherever you need to be, even if you're on the expo floor. Last year, I needed to deliver some swag to a vendor and it took me the better part of 15, 20 minutes to find that vendor on the expo floor using AWS's maps. It's a huge space and it's super convoluted. You need all the help that you can get. And being there in person was absolutely critical in order to understand the challenges that you're facing there, Corey.Corey: People think I'm kidding when I say that, “Oh, you're not going to re:Invent. I envy you. You must be so happy.” Like, people sometimes, if they haven't been, think, “Oh, I'm losing out because I don't have the chance to go to this madhouse event.” It's not as great as you might believe and there's no way to convince people of that until they've been there.I'm disheartened to learn that Google Cloud Next is going to be in Las Vegas next year. That means that's twice a year I'm going to have to schlep there instead of once. At least they're doing it in April, which is otherwise kind of a conference deadzone. But ugh, I am not looking forward to spending even more of my life in Las Vegas than I already have to. I'm there for eight nights a year. It's like crappy Cloud Hanukkah.Jeremy: [laugh]. I second that. To be perfectly honest, San Francisco and Moscone Center, I really enjoy them as venues for these kinds of conferences, but Las Vegas is apparently able to handle things better. I don't know, I'm not real happy about the Vegas situation either, and it takes a toll.Corey: Yeah, I tend to book the next week afterwards of just me lying flat on my back not doing anything. Maybe I'll be sick like I was last year with Covid when we all got it. Maybe I will just be breathing into a bag and trying to recuperate after it. But I know that for mostly the rest of the December, I just don't want to think about cloud too heavily or do too much with it, just because even for me, it's been too much and I need some decompression time.Jeremy: I hear that. I mean, you've had three weeks of Amazon just firehosing everyone with new service releases, new updates, just constantly, and re:Invent caps it all off. And then we get back and there's just no news and everybody's exhausted from being at re:Invent. Everyone's probably sick from being in Las Vegas. To add to that Las Vegas point, hey, there's a bunch of casinos and they're cigarette smoke-filled. Like, it's a miserable place to be. Why do they insist on putting these conferences there?Corey: It drives me nuts and it's one of those things where it's—I mostly feel for the people at Amazon who have to put this show on because yeah, I complain that I don't get much of a Thanksgiving because I have this whole looming event happening, but there are large squadrons of people that they send out in advance for weeks at a time to do things like build out the wireless networks, get everything set up, handle logistics, all of it, and those people forget having, [I think 00:23:35], something hanging over their head during Thanksgiving; they're spending Thanksgiving at… you know, a hotel. That's not fun.Jeremy: No, that's not fun at all. And I understand the stresses that they're under and what these event coordinators are having to deal with. This is a huge event and it's super thankless. That networking team, if things don't work absolutely perfectly and everybody has maximum bandwidth at all times, that poor networking team is going to catch hell, and they just spent weeks getting ready for this. That sucks. I don't really envy them, but I do applaud them and their effort.We've spent the last two [laugh] Thanksgivings planning our own event to make sure things happen smoothly. These big events take a lot of planning, a lot of coordination, and a lot of people. And I think that folks always underestimate that. They underestimate the level of involvement, the level of investment, and what it takes to put on a big show like this.Corey: I mean, there is the counterpoint as well, where we still go because it is the epicenter of the AWS universe. Despite all the complaints I have about it, I like the opportunity to talk to people who are doing interesting things who are building stuff that I'm going to be either using or have inflicted upon me over the next year. And even the community folks, just talking to people who are in the trenches as well, figuring out, okay, AWS built this thing and now I've got to work with it. There's really something to be said for having the opportunity to talk to those people face-to-face. I don't have a whole lot of excuses to go to all the places these people are from, but for one week a year, we all find ourselves in Las Vegas. So, that's at least the silver lining for me. Did you find any silver linings last time or was it simply, “I finally got to go home?”Jeremy: [laugh]. No, actually, I did enjoy it. To your point, getting to speak to the service owners, these people who've written the code, is an amazing opportunity. For example, I got to run into the DeepRacer folks last year before they set up for the tournament, and they were super helpful and super encouraging to get into the DeepRacer program. I explained, “I don't know how to code,” and they said, “That's fine. You can still get into it, you can still learn the basics.”And that's super endearing, that's really supportive, and that's really emblematic of the community that's coming to re:Invent. So, this is a great place to be for this experience, to meet these people, and to associate with other users like yourself. In fact, we're hosting the Atomic Liquors Drink-Up on November 29th for our community who's coming to re:Invent, and we want everybody who's able to come so that we can say hi, pay for your drinks and, you know, talk to us.Corey: Yeah, it starts at 7 p.m. We're co-hosting with RedMonk. No badge needed, no one will scan anything or try to sell you anything. It's just if you want to schlep the three miles from the strip out to Atomic Liquors to hang out with people who are like-minded, it's one of my favorite parts of the show every year. Please, if you're hearing this, you're welcome to come.Jeremy: Absolutely. It's open. No tickets required. It's totally free. I'll be there. Corey will be there—Corey is always there—and it'll be a great time, so I look forward to seeing you there.Corey: Indeed. Jeremy, thank you so much for taking the time out of your increasingly busy day as re:Invent looms ever closer to chat with me for about this stuff. If people want to learn more about what we're up to, where should they go to keep up? I lose track of what URL to send people to.Jeremy: [laugh]. Yeah, thank you for having me, Corey. And the best place to learn about what we're doing at re:Invent is actually requinnvent.com. That's R-E-Q-U-I-N-N-V-E-N-T dot com.Corey: And we'll put a link to that in the [show notes 00:27:33] for sure. Or at least your people will. I have nothing to do with it.Jeremy: Yes, I'll make sure they take care of that. Visit the website. That's where we've got our schedule, all the invites, anything you need to know about what we're doing at re:Invent that week is available on requinnvent.com.Corey: Jeremy, thank you for taking the time to speak with me. I really appreciate it.Jeremy: Thank you, Corey.Corey: Jeremy Tangren, Director of Media Operations here at The Duckbill Group. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment that one of these days someone on Jeremy's team will make it a point to put in front of me. But that day is not today.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
As the tech industry advances at breakneck speed, traditional university programs are struggling to keep pace. Outdated course content and failure to adapt are encouraging developers to go the untraditional route. Can certifications carry the weight of tech education? Dr. Kate Holterhoff, Analyst at RedMonk, is an educator championing certifications in the tech space. Her background in academia, including teaching stints at institutions like Carnegie Mellon and Georgia Tech gave her a wealth of insights on what is best for the future of tech education. Kate sheds light on the challenges faced by tech education, emphasizing the role of community-driven learning, and exploring the impact of certifications on the modern job market. She also explores the contrast between the knowledge gained in traditional universities and the skills demanded by the tech industry. In this episode, Dr. Holterhoff talks to Chuck and Robbie about her thoughts on popular X (Twitter) debates, the shifting landscape of tech education, and the role of certifications in developer education. Key Takeaways [00:43] - Introduction to Dr. Kate Holterhoff. [02:46] - A whiskey review: Hirsch Horizon Bourbon. [09:08] - Tech hot takes. [20:30] - The next chapter for SPAs after the framework wars. [31:15] - Certifications in the tech industry. [50:45] - Kate, Chuck, and Robbie talk about RenderATL. [54:44] - Chuck and Kate talk about restaurants in Cincinnati. Quotes [21:41] - “React isn't going anywhere. So if what you're worried about is a job, React is a good place to go.” ~ Dr. Kate Holterhoff [28:58] - “That's what always comes up when I think about AI. Everyone has got a chatbot now.” ~ Dr. Kate Holterhoff [35:02] - “Folks with CS degrees, information science degrees. They actually have to upskill themselves after they get that degree.” ~ Dr. Kate Holterhoff Links Dr. Kate Holterhoff Dr. Kate Holterhoff Twitter Dr. Kate Holterhoff LinkedIn RedMonk RenderATL Hirsch Horizon Bourbon Twitter LinkedIn Bluesky Mastodon Discord Reddit Bing Slack Instagram React Vue Angular jQuery Facebook Home Depot Tesla Ruby AWS Georgia Institue of Technology iPad Nintendo Switch Kelly Vaughn Chris Coyier Gus's Fried Chicken Red Phone Booth Gold Star Chili Skyline Chili Riverfront Pizza & Sports Bar Connect with our hosts Robbie Wagner Chuck Carpenter Ship Shape Subscribe and stay in touch Apple Podcasts Spotify Google Podcasts Whiskey Web and Whatnot Top-Tier, Full-Stack Software Consultants This show is brought to you by Ship Shape. Ship Shape's software consultants solve complex software and app development problems with top-tier coding expertise, superior service, and speed. In a sea of choices, our senior-level development crew rises above the rest by delivering the best solutions for fintech, cybersecurity, and other fast-growing industries. Check us out at shipshape.io. --- Send in a voice message: https://podcasters.spotify.com/pod/show/whiskey-web-and-whatnot/message
In this special live-recorded episode of Screaming in the Cloud, Corey interviews himself— well, kind of. Corey hosts an AMA session, answering both live and previously submitted questions from his listeners. Throughout this episode, Corey discusses misconceptions about his public persona, the nature of consulting on AWS bills, why he focuses so heavily on AWS offerings, his favorite breakfast foods, and much, much more. Corey shares insights into how he monetizes his public persona without selling out his genuine opinions on the products he advertises, his favorite and least favorite AWS services, and some tips and tricks to get the most out of re:Invent.About CoreyCorey is the Chief Cloud Economist at The Duckbill Group. Corey's unique brand of snark combines with a deep understanding of AWS's offerings, unlocking a level of insight that's both penetrating and hilarious. He lives in San Francisco with his spouse and daughters.Links Referenced: lastweekinaws.com/disclosures: https://lastweekinaws.com/disclosures duckbillgroup.com: https://duckbillgroup.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: As businesses consider automation to help build and manage their hybrid cloud infrastructures, deployment speed is important, but so is cost. Red Hat Ansible Automation Platform is available in the AWS Marketplace to help you meet your cloud spend commitments while delivering best-of-both-worlds support.Corey: Well, all right. Thank you all for coming. Let's begin and see how this whole thing shakes out, which is fun and exciting, and for some godforsaken reason the lights like to turn off, so we're going to see if that continues. I've been doing Screaming in the Cloud for about, give or take, 500 episodes now, which is more than a little bit ridiculous. And I figured it would be a nice change of pace if I could, instead of reaching out and talking to folks who are innovative leaders in the space and whatnot, if I could instead interview my own favorite guest: myself.Because the entire point is, I'm usually the one sitting here asking questions, so I'm instead going to now gather questions from you folks—and feel free to drop some of them into the comments—but I've solicited a bunch of them, I'm going to work through them and see what you folks want to know about me. I generally try to be fairly transparent, but let's have fun with it. To be clear, if this is your first exposure to my Screaming in the Cloud podcast show, it's generally an interview show talking with people involved with the business of cloud. It's not intended to be snarky because not everyone enjoys thinking on their feet quite like that, but rather a conversation of people about what they're passionate about. I'm passionate about the sound of my own voice. That's the theme of this entire episode.So, there are a few that have come through that are in no particular order. I'm going to wind up powering through them, and again, throw some into the comments if you want to have other ones added. If you're listening to this in the usual Screaming in the Cloud place, well, send me questions and I am thrilled to wind up passing out more of them. The first one—a great one to start—comes with someone asked me a question about the video feed. “What's with the Minecraft pickaxe on the wall?” It's made out of foam.One of my favorite stories, and despite having a bunch of stuff on my wall that is interesting and is stuff that I've created, years ago, I wrote a blog post talking about how machine learning is effectively selling digital pickaxes into a gold rush. Because the cloud companies pushing it are all selling things such as, you know, they're taking expensive compute, large amounts of storage, and charging by the hour for it. And in response, Amanda, who runs machine learning analyst relations at AWS, sent me that by way of retaliation. And it remains one of my absolute favorite gifts. It's, where's all this creativity in the machine-learning marketing? No, instead it's, “We built a robot that can think. But what are we going to do with it now? Microsoft Excel.” Come up with some of that creativity, that energy, and put it into the marketing side of the world.Okay, someone else asks—Brooke asks, “What do I think is people's biggest misconception about me?” That's a good one. I think part of it has been my misconception for a long time about what the audience is. When I started doing this, the only people who ever wound up asking me anything or talking to me about anything on social media already knew who I was, so I didn't feel the need to explain who I am and what I do. So, people sometimes only see the witty banter on Twitter and whatnot and think that I'm just here to make fun of things.They don't notice, for example, that my jokes are never calling out individual people, unless they're basically a US senator, and they're not there to make individual humans feel bad about collectively poor corporate decision-making. I would say across the board, people think that I'm trying to be meaner than I am. I'm going to be honest and say it's a little bit insulting, just from the perspective of, if I really had an axe to grind against people who work at Amazon, for example, is this the best I'd be able to do? I'd like to think that I could at least smack a little bit harder. Speaking of, we do have a question that people sent in in advance.“When was the last time that Mike Julian gave me that look?” Easy. It would have been two days ago because we were both in the same room up in Seattle. I made a ridiculous pun, and he just stared at me. I don't remember what the pun is, but I am an incorrigible punster and as a result, Mike has learned that whatever he does when I make a pun, he cannot incorrige me. Buh-dum-tss. That's right. They're no longer puns, they're dad jokes. A pun becomes a dad joke once the punch line becomes a parent. Yes.Okay, the next one is what is my favorite AWS joke? The easy answer is something cynical and ridiculous, but that's just punching down at various service teams; it's not my goal. My personal favorite is the genie joke where a guy rubs a lamp, Genie comes out and says, “You can have a billion dollars if you can spend $100 million in a month, and you're not allowed to waste it or give it away.” And the person says, “Okay”—like, “Those are the rules.” Like, “Okay. Can I use AWS?” And the genie says, “Well, okay, there's one more rule.” I think that's kind of fun.Let's see, another one. A hardball question: given the emphasis on right-sizing for meager cost savings and the amount of engineering work required to make real architectural changes to get costs down, how do you approach cost controls in companies largely running other people's software? There are not as many companies as you might think where dialing in the specifics of a given application across the board is going to result in meaningful savings. Yes, yes, you're running something in hyperscale, it makes an awful lot of sense, but most workloads don't do that. The mistakes you most often see are misconfigurations for not knowing this arcane bit of AWS trivia, as a good example. There are often things you can do with relatively small amounts of effort. Beyond a certain point, things are going to cost what they're going to cost without a massive rearchitecture and I don't advise people do that because no one is going to be happy rearchitecting just for cost reasons. Doesn't go well.Someone asks, “I'm quite critical of AWS, which does build trust with the audience. Has AWS tried to get you to market some of their services, and would I be open to do that?” That's a great question. Yes, sometimes they do. You can tell this because they wind up buying ads in the newsletter or the podcast and they're all disclaimed as a sponsored piece of content.I do have an analyst arrangement with a couple of different cloud companies, as mentioned lastweekinaws.com/disclosures, and the reason behind that is because you can buy my attention to look at your product and talk to you in-depth about it, but you cannot buy my opinion on it. And those engagements are always tied to, let's talk about what the public is seeing about this. Now, sometimes I write about the things that I'm talking about because that's where my mind goes, but it's not about okay, now go and talk about this because we're paying you to, and don't disclose that you have a financial relationship.No, that is called fraud. I figure I can sell you as an audience out exactly once, so I better be able to charge enough money to never have to work again. Like, when you see me suddenly talk about multi-cloud being great and I became a VP at IBM, about three to six months after that, no one will ever hear from me again because I love nesting doll yacht money. It'll be great.Let's see. The next one I have on my prepared list here is, “Tell me about a time I got AWS to create a pie chart.” I wish I'd see less of it. Every once in a while I'll talk to a team and they're like, “Well, we've prepared a PowerPoint deck to show you what we're talking about.” No, Amazon is famously not a PowerPoint company and I don't know why people feel the need to repeatedly prove that point to me because slides are not always the best way to convey complex information.I prefer to read documents and then have a conversation about them as Amazon tends to do. The visual approach and the bullet lists and all the rest are just frustrating. If I'm going to do a pie chart, it's going to be in service of a joke. It's not going to be anything that is the best way to convey information in almost any sense.“How many internal documents do I think reference me by name at AWS,” is another one. And I don't know the answer to documents, but someone sent me a screenshot once of searching for my name in their Slack internal nonsense thing, and it was about 10,000 messages referenced me that it found. I don't know what they were saying. I have to assume, on some level, just something that does a belt feed from my Twitter account where it lists my name or something. But I choose to believe that no, they actually are talking about me to that level of… of extreme.Let's see, let's turn back to the chat for a sec because otherwise it just sounds like I'm doing all prepared stuff. And I'm thrilled to do that, but I'm also thrilled to wind up fielding questions from folks who are playing along on these things. “I love your talk, ‘Heresy in the Church of Docker.' Do I have any more speaking gigs planned?” Well, today's Wednesday, and this Friday, I have a talk that's going out at the CDK Community Day.I also have a couple of things coming up that are internal corporate presentations at various places. But at the moment, no. I suspect I'll be giving a talk if they accept it at SCALE in Pasadena in March of next year, but at the moment, I'm mostly focused on re:Invent, just because that is eight short weeks away and I more or less destroy the second half of my year because… well, holidays are for other people. We're going to talk about clouds, as Amazon and the rest of us dance to the tune that they play.“Look in my crystal ball; what will the industry look like in 5, 10, or 20 years?” Which is a fun one. You shouldn't listen to me on this. At all. I was the person telling you that virtualization was a flash in the pan, that cloud was never going to catch on, that Kubernetes and containers had a bunch of problems that were unlikely to be solved, and I'm actually kind of enthused about serverless which probably means it's going to flop.I am bad at predicting overall trends, but I have no problem admitting that wow, I was completely wrong on that point, which apparently is a rarer skill than it should be. I don't know what the future the industry holds. I know that we're seeing some AI value shaping up. I think that there's going to be a bit of a downturn in that sector once people realize that just calling something AI doesn't mean you make wild VC piles of money anymore. But there will be use cases that filter out of it. I don't know what they're going to look like yet, but I'm excited to see it.Okay, “Have any of the AWS services increased costs in the last year? I was having a hard time finding historical pricing charts for services.” There have been repricing stories. There have been SMS charges in India that have—and pinpointed a few other things—that wound up increasing because of a government tariff on them and that cost was passed on. Next February, they're going to be charging for public IPV4 addresses.But those tend to be the exceptions. The way that most costs tend increase have been either, it becomes far cheaper for AWS to provide a service and they don't cut the cost—data transfer being a good example—they'll also often have stories in that they're going to start launching a bunch of new things, and you'll notice that AWS bills tend to grow in time. Part of that growth, part of that is just cruft because people don't go back and clean things up. But by and large, I have not seen, “This thing that used to cost you $1 is now going to cost you $2.” That's not how AWS does pricing. Thankfully. Everyone's always been scared of something like that happening. I think that when we start seeing actual increases like that, that's when it's time to start taking a long, hard look at the way that the industry is shaping up. I don't think we're there yet.Okay. “Any plans for a Last Week in Azure or a Last Week in GCP?” Good question. If so, I won't be the person writing it. I don't think that it's reasonable to expect someone to keep up with multiple large companies and their releases. I'd also say that Azure and GCP don't release updates to services with the relentless cadence that AWS does.The reason I built the thing to start with is simply because it was difficult to gather all the information in one place, at least the stuff that I cared about with an economic impact, and by the time I'd done that, it was, well, this is 80% of the way toward republishing it for other people. I expected someone was going to point me at a thing so I didn't have to do it, and instead, everyone signed up. I don't see the need for it. I hope that in those spaces, they're better at telling their own story to the point where the only reason someone would care about a newsletter would be just my sarcasm tied into whatever was released. But that's not something that I'm paying as much attention to, just because my customers are on AWS, my stuff is largely built on AWS, it's what I have to care about.Let's see here. “What do I look forward to at re:Invent?” Not being at re:Invent anymore. I'm there for eight nights a year. That is shitty cloud Chanukah come to life for me. I'm there to set things up in advance, I'm there to tear things down at the end, and I'm trying to have way too many meetings in the middle of all of that. I am useless for the rest of the year after re:Invent, so I just basically go home and breathe into a bag forever.I had a revelation last year about re:Play, which is that I don't have to go to it if I don't want to go. And I don't like the cold, the repetitive music, the giant crowds. I want to go read a book in a bathtub and call it a night, and that's what I hope to do. In practice, I'll probably go grab dinner with other people who feel the same way. I also love the Drink Up I do there every year over at Atomic Liquors. I believe this year, we're partnering with the folks over at RedMonk because a lot of the people we want to talk to are in the same groups.It's just a fun event: show up, let us buy you drinks. There's no badge scan or any nonsense like that. We just want to talk to people who care to come out and visit. I love doing that. It's probably my favorite part of re:Invent other than not being at re:Invent. It's going to be on November 29th this year. If you're listening to this, please come on by if you're unfortunate enough to be in Las Vegas.Someone else had a good question I want to talk about here. “I'm a TAM for AWS. Cost optimization is one of our functions. What do you wish we would do better after all the easy button things such as picking the right instance and family, savings plans RIs, turning off or delete orphan resources, watching out for inefficient data transfer patterns, et cetera?” I'm going to back up and say that you're begging the question here, in that you aren't doing the easy things, at least not at scale, not globally.I used to think that all of my customer engagements would be, okay after the easy stuff, what's next? I love those projects, but in so many cases, I show up and those easy things have not been done. “Well, that just means that your customers haven't been asking their TAM.” Every customer I've had has asked their TAM first. “Should we ask the free expert or the one that charges us a large but reasonable fixed fee? Let's try the free thing first.”The quality of that advice is uneven. I wish that there were at least a solid baseline. I would love to get to a point where I can assume that I can go ahead and be able to just say, “Okay, you've clearly got your RI stuff, you're right-sizing, you're deleting stuff you're not using, taken care of. Now, let's look at the serious architecture stuff.” It's just rare that I get to see it.“What tool, feature, or widget do I wish AWS would build into the budget console?” I want to be able to set a dollar figure, maybe it's zero, maybe it's $20, maybe it is irrelevant, but above whatever I set, the account will not charge me above that figure, period. If that means they have to turn things off if that means they had to delete portions of data, great. But I want that assurance because even now when I kick the tires in a new service, I get worried that I'm going to wind up with a surprise bill because I didn't understand some very subtle interplay of the dynamics. And if I'm worried about that, everyone else is going to wind up getting caught by that stuff, too.I want the freedom to experiment and if it smacks into a wall, okay, cool. That's $20. That was worth learning that. Whatever. I want the ability to not be charged unreasonable overages. And I'm not worried about it turning from 20 into 40. I'm worried about it turning from 20 into 300,000. Like, there's the, “Oh, that's going to have a dent on the quarterlies,” style of [numb 00:16:01]—All right. Someone also asked, “What is the one thing that AWS could do that I believe would reduce costs for both AWS and their customers. And no, canceling re:Invent doesn't count.” I don't think about it in that way because believe it or not, most of my customers don't come to me asking to reduce their bill. They think they do at the start, but what they're trying to do is understand it. They're trying to predict it.Yes, they want to turn off the waste in the rest, but by and large, there are very few AWS offerings that you take a look at and realize what you're getting for it and say, “Nah, that's too expensive.” It can be expensive for certain use cases, but the dangerous part is when the costs are unpredictable. Like, “What's it going to cost me to run this big application in my data center?” The answer is usually, “Well, run it for a month, and then we'll know.” But that's an expensive and dangerous way to go about finding things out.I think that customers don't care about reducing costs as much as they think; they care about controlling them, predicting them, and understanding them. So, how would they make things less expensive? I don't know. I suspect that data transfer if they were to reduce that at least cross-AZ or eliminate it ideally, you'd start seeing a lot more compute usage in multiple AZs. I've had multiple clients who are not spinning things up in multi-AZ, specifically because they'll take the reliability trade-off over the extreme cost of all the replication flowing back and forth. Aside from that, they mostly get a lot of the value right in how they price things, which I don't think people have heard me say before, but it is true.Someone asked a question here of, “Any major trends that I'm seeing in EDP/PPA negotiations?” Yeah, lately, in particular. Used to be that you would have a Marketplace as the fallback, where it used to be that 50 cents of every dollar you spent on Marketplace would count. Now, it's a hundred percent up to a quarter of your commit. Great.But when you have a long-term commitment deal with Amazon, now they're starting to push for all—put all your other vendors onto the AWS Marketplace so you can have a bigger commit and thus a bigger discount, which incidentally, the discount does not apply to Marketplace spend. A lot of folks are uncomfortable with having Amazon as the middleman between all of their vendor relationships. And a lot of the vendors aren't super thrilled with having to pay percentages of existing customer relationships to Amazon for what they perceive to be remarkably little value. That's the current one.I'm not seeing generative AI play a significant stake in this yet. People are still experimenting with it. I'm not seeing, “Well, we're spending $100 million a year, but make that 150 because of generative AI.” It's expensive to play with gen-AI stuff, but it's not driving the business spend yet. But that's the big trend that I'm seeing over the past, eh, I would say, few months.“Do I use AWS for personal projects?” The first problem there is, well, what's a personal project versus a work thing? My life is starting to flow in a bunch of weird different ways. The answer is yes. Most of the stuff that I build for funsies is on top of AWS, though there are exceptions. “Should I?” Is the follow-up question and the answer to that is, “It depends.”The person is worrying about cost overruns. So, am I. I tend to not be a big fan of uncontrolled downside risk when something winds up getting exposed. I think that there are going to be a lot of caveats there. I know what I'm doing and I also have the backstop, in my case, of, I figure I can have a big billing screw-up or I have to bend the knee and apologize and beg for a concession from AWS, once.It'll probably be on a billboard or something one of these days. Lord knows I have it coming to me. That's something I can use as a get-out-of-jail-free card. Most people can't make that guarantee, and so I would take—if—depending on the environment that you know and what you want to build, there are a lot of other options: buying a fixed-fee VPS somewhere if that's how you tend to think about things might very well be a cost-effective for you, depending on what you're building. There's no straight answer to this.“Do I think Azure will lose any market share with recent cybersecurity kerfuffles specific to Office 365 and nation-state actors?” No, I don't. And the reason behind that is that a lot of Azure spend is not necessarily Azure usage; it's being rolled into enterprise agreements customers negotiate as part of their on-premises stuff, their operating system licenses, their Office licensing, and the rest. The business world is not going to stop using Excel and Word and PowerPoint and Outlook. They're not going to stop putting Windows on desktop stuff. And largely, customers don't care about security.They say they do, they often believe that they do, but I see where the bills are. I see what people spend on feature development, I see what they spend on core infrastructure, and I see what they spend on security services. And I have conversations about budgeting with what are you doing with a lot of these things? The companies generally don't care about this until right after they really should have cared. And maybe that's a rational effect.I mean, take a look at most breaches. And a year later, their stock price is larger than it was when they dispose the breach. Sure, maybe they're burning through their ablated CISO, but the business itself tends to succeed. I wish that there were bigger consequences for this. I have talked to folks who will not put specific workloads on Azure as a result of this. “Will you talk about that publicly?” “No, because who can afford to upset Microsoft?”I used to have guests from Microsoft on my show regularly. They don't talk to me and haven't for a couple of years. Scott Guthrie, the head of Azure, has been on this show. The problem I have is that once you start criticizing their security posture, they go quiet. They clearly don't like me.But their options are basically to either ice me out or play around with my seven seats for Office licensing, which, okay, whatever. They don't have a stick to hit me with, in the way that they do most companies. And whether that's true or not that they're going to lash out like that, companies don't want to take the risk of calling Microsoft out in public. Too big to be criticized as sort of how that works.Let's see, someone else asks, “How can a startup get the most out of its startup status with AWS?” You're not going to get what you think you want from AWS in this context. “Oh, we're going to be a featured partner so they market us.” I've yet to hear a story about how being featured by AWS for something has dramatically changed the fortunes of a startup. Usually, they'll do that when there's either a big social mission and you never hear about the company again, or they're a darling of the industry that's taking the world by fire and they're already [at 00:22:24] upward swing and AWS wants to hang out with those successful people in public and be seen to do so.The actual way that startup stuff is going to manifest itself well for you from AWS is largely in the form of credits as you go through Activate or one of their other programs. But be careful. Treat them like actual money, not this free thing you don't have to worry about. One day they expire or run out and suddenly you're going from having no dollars going to AWS to ten grand a month and people aren't prepared for that. It's, “Wait. So you mean this costs money? Oh, my God.”You have to approach it with a sense of discipline. But yeah, once you—if you can do that, yeah, free money and a free cloud bill for a few years? That's not nothing. I also would question the idea of being able to ask a giant company that's worth a trillion-and-a-half dollars and advice for how to be a startup. I find that one's always a little on the humorous side myself.“What do I think is the most underrated service or feature release from 2023? Full disclosures, this means I'll make some content about it,” says Brooke over at AWS. Oh, that's a good question. I'm trying to remember when various things have come out and it all tends to run together. I think that people are criticizing AWS for charging for IPV4 an awful lot, and I think that that is a terrific change, just because I've seen how wasteful companies are with public IP addresses, which are basically an exhausted or rapidly exhausting resource.And they just—you spend tens or hundreds of thousands of these things and don't use reason to think about that. It'll be one of the best things that we've seen for IPV6 adoption once AWS figures out how to make that work. And I would say that there's a lot to be said for since, you know, IPV4 is exhausted already, now we're talking about can we get them on the secondary markets, you need a reasonable IP plan to get some of those. And… “Well, we just give them the customers and they throw them away.” I want AWS to continue to be able to get those for the stuff that the rest of us are working on, not because one big company uses a million of them, just because, “Oh, what do you mean private IP addresses? What might those be?” That's part of it.I would say that there's also been… thinking back on this, it's unsung, the compute optimizer is doing a lot better at recommending things than it used to be. It was originally just giving crap advice, and over time, it started giving advice that's actually solid and backs up what I've seen. It's not perfect, and I keep forgetting it's there because, for some godforsaken reason, it's its own standalone service, rather than living in the billing console where it belongs. But no one's excited about a service like that to the point where they talk about or create content about it, but it's good, and it's getting better all the time. That's probably a good one. They recently announced the ability for it to do GPU instances which, okay great, for people who care about that, awesome, but it's not exciting. Even I don't think I paid much attention to it in the newsletter.Okay, “Does it make economic sense to bring your own IP addresses to AWS instead of paying their fees?” Bring your own IP, if you bring your own allocation to AWS, costs you nothing in terms of AWS costs. You take a look at the market rate per IP address versus what AWS costs, you'll hit break even within your first year if you do it. So yeah, it makes perfect economic sense to do it if you have the allocation and if you have the resourcing, as well as the ability to throw people at the problem to do the migration. It can be a little hairy if you're not careful. But the economics, the benefit is clear on that once you account for those variables.Let's see here. We've also got tagging. “Everyone nods their heads that they know it's the key to controlling things, but how effective are people at actually tagging, especially when new to cloud?” They're terrible at it. They're never going to tag things appropriately. Automation is the way to do it because otherwise, you're going to spend the rest of your life chasing developers and asking them to tag things appropriately, and then they won't, and then they'll feel bad about it. No one enjoys that conversation.So, having derived tags and the rest, or failing that, having some deployment gate as early in the process as possible of, “Oh, what's the tag for this?” Is the only way you're going to start to see coverage on this. And ideally, someday you'll go back and tag a bunch of pre-existing stuff. But it's honestly the thing that everyone hates the most on this. I have never seen a company that says, “We are thrilled with our with our tag coverage. We're nailing it.” The only time you see that is pure greenfield, everything done without ClickOps, and those environments are vanishingly rare.“Outside a telecom are customers using local zones more, or at all?” Very, very limited as far as what their usage looks like on that. Because that's… it doesn't buy you as much as you'd think for most workloads. The real benefit is a little more expensive, but it's also in specific cities where there are not AWS regions, and at least in the United States where the majority of my clients are, there is not meaningful latency differences, for example, from in Los Angeles versus up to Oregon, since no one should be using the Northern California region because it's really expensive. It's a 20-millisecond round trip, which in most cases, for most workloads, is fine.Gaming companies are big exception to this. Getting anything they can as close to the customer as possible is their entire goal, which very often means they don't even go with some of the cloud providers in some places. That's one of those actual multi-cloud workloads that you want to be able to run anywhere that you can get a baseline computer up to run a container or a golden image or something. That is the usual case. The rest are, for local zones, is largely going to be driven by specific one-off weird things. Good question.Let's see, “Is S3 intelligent tiering good enough or is it worth trying to do it yourself?” Your default choice for almost everything should be intelligent tiering in 2023. It winds up costing you more only in very specific circumstances that are unlikely to be anything other than a corner case for what you're doing. And the exceptions to this are, large workloads that are running a lot of S3 stuff where the lifecycle is very well understood, environments where you're not going to be storing your data for more than 30 days in any case and you can do a lifecycle policy around it. Other than those use cases, yeah, the monitoring fee is not significant in any environment I've ever seen.And people view—touch their data a lot less than they believe. So okay, there's a monitoring fee for object, yes, but it also cuts your raw storage cost in half for things that aren't frequently touched. So, you know, think about it. Run your own numbers and also be aware that first month as it transitions in, you're going to see massive transition charges per object, but wants it's an intelligent tiering, there's no further transition charges, which is nice.Let's see here. “We're all-in on serverless”—oh good, someone drank the Kool-Aid, too—“And for our use cases, it works great. Do I find other customers moving to it and succeeding?” Yeah, I do when they're moving to it because for certain workloads, it makes an awful lot of sense. For others, it requires a complete reimagining of whatever it is that you're doing.The early successes were just doing these periodic jobs. Now, we're seeing full applications built on top of event-driven architectures, which is really neat to see. But trying to retrofit something that was never built with that in mind can be more trouble than it's worth. And there are corner cases where building something on serverless would cost significantly more than building it in a server-ful way. But its time has come for an awful lot of stuff. Now, what I don't subscribe to is this belief that oh, if you're not building something serverless you're doing it totally wrong. No, that is not true. That has never been true.Let's see what else have we got here? Oh, “Following up on local zones, how about Outposts? Do I see much adoption? What's the primary use case or cases?” My customers inherently are coming to me because of a large AWS bill. If they're running Outposts, it is extremely unlikely that they are putting significant portions of their spend through the Outpost. It tends to be something of a rounding error, which means I don't spend a lot of time focusing on it.They obviously have some existing data center workloads and data center facilities where they're going to take an AWS-provided rack and slap it in there, but it's not going to be in the top 10 or even top 20 list of service spend in almost every case as a result, so it doesn't come up. One of the big secrets of how we approach things is we start with a big number first and then work our way down instead of going alphabetically. So yes, I've seen customers using them and the customers I've talked to at re:Invent who are using them are very happy with them for the use cases, but it's not a common approach. I'm not a huge fan of the rest.“Someone said the Basecamp saved a million-and-a-half a year by leaving AWS. I know you say repatriation isn't a thing people are doing, but has my view changed at all since you've published that blog post?” No, because everyone's asking me about Basecamp and it's repatriation, and that's the only use case that they've got for this. Let's further point out that a million-and-a-half a year is not as many engineers as you might think it is when you wind up tying that all together. And now those engineers are spending time running that environment.Does it make sense for them? Probably. I don't know their specific context. I know that a million-and-a-half dollars a year to—even if they had to spend that for the marketing coverage that they're getting as a result of this, makes perfect sense. But cloud has never been about raw cost savings. It's about feature velocity.If you have a data center and you move it to the cloud, you're not going to recoup that investment for at least five years. Migrations are inherently expensive. It does not create the benefits that people often believe that they do. That becomes a painful problem for folks. I would say that there's a lot more noise than there are real-world stories [hanging 00:31:57] out about these things.Now, I do occasionally see a specific workload that is moved back to a data center for a variety of reasons—occasionally cost but not always—and I see proof-of-concept projects that they don't pursue and then turn off. Some people like to call that a repatriation. No, I call it as, “We tried and it didn't do what we wanted it to do so we didn't proceed.” Like, if you try that with any other project, no one says, “Oh, you're migrating off of it.” No, you're not. You tested it, it didn't do what it needed to do. I do see net-new workloads going into data centers, but that's not the same thing.Let's see. “Are the talks at re:Invent worth it anymore? I went to a lot of the early re:Invents and haven't and about five years. I found back then that even the level 400 talks left a lot to be desired.” Okay. I'm not a fan of attending conference talks most of the time, just because there's so many things I need to do at all of these events that I would rather spend the time building relationships and having conversations.The talks are going to be on YouTube a week later, so I would rather get to know the people building the service so I can ask them how to inappropriately use it as a database six months later than asking questions about the talk. Conference-ware is often the thing. Re:Invent always tends to have an AWS employee on stage as well. And I'm not saying that makes these talks less authentic, but they're also not going to get through slide review of, “Well, we tried to build this onto this AWS service and it was a terrible experience. Let's tell you about that as a war story.” Yeah, they're going to shoot that down instantly even though failure stories are so compelling, about here's what didn't work for us and how we got there. It's the lessons learned type of thing.Whenever you have as much control as re:Invent exhibits over its speakers, you know that a lot of those anecdotes are going to be significantly watered down. This is not to impugn any of the speakers themselves; this is the corporate mind continuing to grow to a point where risk mitigation and downside protection becomes the primary driving goal.Let's pull up another one from the prepared list here. “My most annoying, overpriced, or unnecessary charge service in AWS.” AWS Config. It's a tax on using the cloud as the cloud. When you have a high config bill, it's because it charges you every time you change the configuration of something you have out there. It means you're spinning up and spinning down EC2 instances, whereas you're going to have a super low config bill if you, you know, treat it like a big dumb data center.It's a tax on accepting the promises under which cloud has been sold. And it's necessary for a number of other things like Security Hub. Control Towers magic-deploys it everywhere and makes it annoying to turn off. And I think that that is a pure rent-seeking charge because people aren't incurring config charges if they're not already using a lot of AWS things. Not every service needs to make money in a vacuum. It's, “Well, we don't charge anything for this because our users are going to spend an awful lot of money on storing things in S3 to use our service.” Great. That's a good thing. You don't have to pile charge upon charge upon charge upon charge. It drives me a little bit nuts.Let's see what else we have here as far as questions go. “Which AWS service delights me the most?” Eesh, depends on the week. S3 has always been a great service just because it winds up turning big storage that usually—used to require a lot of maintenance and care into something I don't think about very much. It's getting smarter and smarter all the time. The biggest lie is the ‘Simple' in its name: ‘Simple Storage Service.' At this point, if that's simple, I really don't want to know what you think complex would look like.“By following me on Twitter, someone gets a lot of value from things I mention offhandedly as things everybody just knows. For example, which services are quasi-deprecated or outdated, or what common practices are anti-patterns? Is there a way to learn this kind of thing all in one go, as in a website or a book that reduces AWS to these are the handful of services everybody actually uses, and these are the most commonly sensible ways to do it?” I wish. The problem is that a lot of the stuff that everyone knows, no, it's stuff that at most, maybe half of the people who are engaging with it knew.They find out by hearing from other people the way that you do or by trying something and failing and realizing, ohh, this doesn't work the way that I want it to. It's one of the more insidious forms of cloud lock-in. You know how a service works, how a service breaks, what the constraints are around when it starts and it stops. And that becomes something that's a hell of a lot scarier when you have to realize, I'm going to pick a new provider instead and relearn all of those things. The reason I build things on AWS these days is honestly because I know the ways it sucks. I know the painful sharp edges. I don't have to guess where they might be hiding. I'm not saying that these sharp edges aren't painful, but when you know they're there in advance, you can do an awful lot to guard against that.“Do I believe the big two—AWS and Azure—cloud providers have agreed between themselves not to launch any price wars as they already have an effective monopoly between them and [no one 00:36:46] win in a price war?” I don't know if there's ever necessarily an explicit agreement on that, but business people aren't foolish. Okay, if we're going to cut our cost of service, instantly, to undercut a competitor, every serious competitor is going to do the same thing. The only reason to do that is if you believe your margins are so wildly superior to your competitors that you can drive them under by doing that or if you have the ability to subsidize your losses longer than they can remain a going concern. Microsoft and Amazon are—and Google—are not in a position where, all right, we're going to drive them under.They can both subsidize losses basically forever on a lot of these things and they realize it's a game you don't win in, I suspect. The real pricing pressure on that stuff seems to come from customers, when all right, I know it's big and expensive upfront to buy a SAN, but when that starts costing me less than S3 on a per-petabyte basis, that's when you start to see a lot of pricing changing in the market. The one thing I haven't seen that take effect on is data transfer. You could be forgiven for believing that data transfer still cost as much as it did in the 1990s. It does not.“Is AWS as far behind in AI as they appear?” I think a lot of folks are in the big company space. And they're all stammering going, “We've been doing this for 20 years.” Great, then why are all of your generative AI services, A, bad? B, why is Alexa so terrible? C, why is it so clear that everything you have pre-announced and not brought to market was very clearly not envisioned as a product to be going to market this year until 300 days ago, when Chat-Gippity burst onto the scene and OpenAI [stole a march 00:38:25] on everyone?Companies are sprinting to position themselves as leaders in the AI space, despite the fact that they've gotten lapped by basically a small startup that's seven years old. Everyone is trying to work the word AI into things, but it always feels contrived to me. Frankly, it tells me that I need to just start tuning the space out for a year until things settle down and people stop describing metric math or anomaly detection is AI. Stop it. So yeah, I'd say if anything, they're worse than they appear as far as from behind goes.“I mostly focus on AWS. Will I ever cover Azure?” There are certain things that would cause me to do that, but that's because I don't want to be the last Perl consultancy is the entire world has moved off to Python. And effectively, my focus on AWS is because that's where the painful problems I know how to fix live. But that's not a suicide pact. I'm not going to ride that down in flames.But I can retool for a different cloud provider—if that's what the industry starts doing—far faster than AWS can go from its current market-leading status to irrelevance. There are certain triggers that would cause me to do that, but at the time, I don't see them in the near term and I don't have any plans to begin covering other things. As mentioned, people want me to talk about the things I'm good at not the thing that makes me completely nonsensical.“Which AWS services look like a good idea, but pricing-wise, they're going to kill you once you have any scale, especially the ones that look okay pricing-wise but aren't really and it's hard to know going in?” CloudTrail data events, S3 Bucket Access logging any of the logging services really, Managed NAT Gateways in a bunch of cases. There's a lot that starts to get really expensive once you hit certain points of scale with a corollary that everyone thinks that everything they're building is going to scale globally and that's not true. I don't build things as a general rule with the idea that I'm going to get ten million users on it tomorrow because by the time I get from nothing to substantial workloads, I'm going to have multiple refactors of what I've done. I want to get things out the door as fast as possible and if that means that later in time, oh, I accidentally built Pinterest. What am I going to do? Well, okay, yeah, I'm going to need to rebuild a whole bunch of stuff, but I'll have the user traffic and mindshare and market share to finance that growth.Early optimization on stuff like this causes a lot more problems than it solves. “Best practices and anti-patterns in managing AWS costs. For context, you once told me about a role that I had taken that you'd seen lots of companies tried to create that role and then said that the person rarely lasts more than a few months because it just isn't effective. You were right, by the way.” Imagine that I sometimes know what I'm talking about.When it comes to managing costs, understand what your goal is here, what you're actually trying to achieve. Understand it's going to be a cross-functional work between people in finance and people that engineering. It is first and foremost, an engineering problem—you learn that at your peril—and making someone be the human gateway to spin things up means that they're going to quit, basically, instantly. Stop trying to shame different teams without understanding their constraints.Savings Plans are a great example. They apply biggest discount first, which is what you want. Less money going out the door to Amazon, but that makes it look like anything with a low discount percentage, like any workload running on top of Microsoft Windows, is not being responsible because they're always on demand. And you're inappropriately shaming a team for something completely out of their control. There's a point where optimization no longer makes sense. Don't apply it to greenfield projects or skunkworks. Things you want to see if the thing is going to work first. You can optimize it later. Starting out with a, ‘step one: spend as little as possible' is generally not a recipe for success.What else have we got here? I've seen some things fly by in the chat that are probably worth mentioning here. Some of it is just random nonsense, but other things are, I'm sure, tied to various questions here. “With geopolitics shaping up to govern tech data differently in each country, does it make sense to even build a globally distributed B2B SaaS?” Okay, I'm going to tackle this one in a way that people will probably view as a bit of an attack, but it's something I see asked a lot by folks trying to come up with business ideas.At the outset, I'm a big believer in, if you're building something, solve it for a problem and a use case that you intrinsically understand. That is going to mean the customers with whom you speak. Very often, the way business is done in different countries and different cultures means that in some cases, this thing that's a terrific idea in one country is not going to see market adoption somewhere else. There's a better approach to build for the market you have and the one you're addressing rather than aspirational builds. I would also say that it potentially makes sense if there are certain things you know are going to happen, like okay, we validated our marketing and yeah, it turns out that we're building an image resizing site. Great. People in Germany and in the US all both need to resize images.But you know, going in that there's going to be a data residency requirement, so architecting, from day one with an idea that you can have a partition that winds up storing its data separately is always going to be to your benefit. I find aligning whatever you're building with the idea of not being creepy is often a great plan. And there's always the bring your own storage approach to, great, as a customer, you can decide where your data gets stored in your account—charge more for that, sure—but then that na—it becomes their problem. Anything that gets you out of the regulatory critical path is usually a good idea. But with all the problems I would have building a business, that is so far down the list for almost any use case I could ever see pursuing that it's just one of those, you have a half-hour conversation with someone who's been down the path before if you think it might apply to what you're doing, but then get back to the hard stuff. Like, worry on the first two or three steps rather than step 90 just because you'll get there eventually. You don't want to make your future life harder, but you also don't want to spend all your time optimizing early, before you've validated you're actually building something useful.“What unique feature of AWS do I most want to see on other cloud providers and vice versa?” The vice versa is easy. I love that Google Cloud by default has the everything in this project—which is their account equivalent—can talk to everything else, which means that humans aren't just allowing permissions to the universe because it's hard. And I also like that billing is tied to an individual project. ‘Terminate all billable resources in this project' is a button-click away and that's great.Now, what do I wish other cloud providers would take from AWS? Quite honestly, the customer obsession. It's still real. I know it sounds like it's a funny talking point or the people who talk about this the most under the cultists, but they care about customer problems. Back when no one had ever heard of me before and my AWS Bill was seven bucks, whenever I had a problem with a service and I talked about this in passing to folks, Amazonians showed up out of nowhere to help make sure that my problem got answered, that I was taken care of, that I understood what I was misunderstanding, or in some cases, the feedback went to the product team.I see too many companies across the board convinced that they themselves know best about what customers need. That occasionally can be true, but not consistently. When customers are screaming for something, give them what they need, or frankly, get out of the way so someone else can. I mean, I know someone's expecting me to name a service or something, but we've gotten past the point, to my mind, of trying to do an apples-to-oranges comparison in terms of different service offerings. If you want to build a website using any reasonable technology, there's a whole bunch of companies now that have the entire stack for you. Pick one. Have fun.We've got time for a few more here. Also, feel free to drop more questions in. I'm thrilled to wind up answering any of these things. Have I seen any—here's one that about Babelfish, for example, from Justin [Broadly 00:46:07]. “Have I seen anyone using Babelfish in the wild? It seems like it was a great idea that didn't really work or had major trade-offs.”It's a free open-source project that translates from one kind of database SQL to a different kind of database SQL. There have been a whole bunch of attempts at this over the years, and in practice, none of them have really panned out. I have seen no indications that Babelfish is different. If someone at AWS works on this or is a customer using Babelfish and say, “Wait, that's not true,” please tell me because all I'm saying is I have not seen it and I don't expect that I will. But I'm always willing to be wrong. Please, if I say something at some point that someone disagrees with, please reach out to me. I don't intend to perpetuate misinformation.“Purely hypothetically”—yeah, it's always great to ask things hypothetically—“In the companies I work with, which group typically manages purchasing savings plans, the ops team, finance, some mix of both?” It depends. The sad answer is, “What's a savings plan,” asks the company, and then we have an educational path to go down. Often it is individual teams buying them ad hoc, which can work, cannot as long as everyone's on the same page. Central planning, in a bunch of—a company that's past a certain point in sophistication is where everything winds up leading to.And that is usually going to be a series of discussions, ideally run by that group in a cross-functional way. They can be cost engineering, they can be optimization engineering, I've heard it described in a bunch of different ways. But that is—increasingly as the sophistication of your business and the magnitude of your spend increases, the sophistication of how you approach this should change as well. Early on, it's the offense of some VP of engineering at a startup. Like, “Oh, that's a lot of money,” running the analyzer and clicking the button to buy what it says. That's not a bad first-pass attempt. And then I think getting smaller and smaller buys as you continue to proceed means you can start to—it no longer becomes the big giant annual decision and instead becomes part of a frequently used process. That works pretty well, too.Is there anything else that I want to make sure I get to before we wind up running this down? To the folks in the comments, this is your last chance to throw random, awkward questions my way. I'm thrilled to wind up taking any slings, arrows, et cetera, that you care to throw my way a going once, going twice style. Okay, “What is the most esoteric or shocking item on the AWS bill that you ever found with one of your customers?” All right, it's been long enough, and I can say it without naming the customer, so that'll be fun.My personal favorite was a high five-figure bill for Route 53. I joke about using Route 53 as a database. It can be, but there are better options. I would say that there are a whole bunch of use cases for Route 53 and it's a great service, but when it's that much money, it occasions comment. It turned out that—we discovered, in fact, a data exfiltration in progress which made it now a rather clever security incident.And, “This call will now be ending for the day and we're going to go fix that. Thanks.” It's like I want a customer testimonial on that one, but for obvious reasons, we didn't get one. But that was probably the most shocking thing. The depressing thing that I see the most—and this is the core of the cost problem—is not when the numbers are high. It's when I ask about a line item that drives significant spend, and the customer is surprised.I don't like it when customers don't know what they're spending money on. If your service surprises customers when they realize what it costs, you have failed. Because a lot of things are expensive and customers know that and they're willing to take the value in return for the cost. That's fine. But tricking customers does not serve anyone well, even your own long-term interests. I promise.“Have I ever had to reject a potential client because they had a tangled mess that was impossible to tackle, or is there always a way?” It's never the technology that will cause us not to pursue working with a given company. What will is, like, if you go to our website at duckbillgroup.com, you're not going to see a ‘Buy Here' button where you ‘add one consulting, please' to your shopping cart and call it a day.It's a series of conversations. And what we will try to make sure is, what is your goal? Who's aligned with it? What are the problems you're having in getting there? And what does success look like? Who else is involved in this? And it often becomes clear that people don't like the current situation, but there's no outcome with which they would be satisfied.Or they want something that we do not do. For example, “We want you to come in and implement all of your findings.” We are advisory. We do not know the specifics of your environment and—or your deployment processes or the rest. We're not an engineering shop. We charge a fixed fee and part of the way we can do that is by controlling the scope of what we do. “Well, you know, we have some AWS bills, but we really want to—we really care about is our GCP bill or our Datadog bill.” Great. We don't focus on either of those things. I mean, I can just come in and sound competent, but that's not what adding value as a consultant is about. It's about being authoritatively correct. Great question, though.“How often do I receive GovCloud cost optimization requests? Does the compliance and regulation that these customers typically have keep them from making the needed changes?” It doesn't happen often and part of the big reason behind that is that when we're—and if you're in GovCloud, it's probably because you are a significant governmental entity. There's not a lot of private sector in GovCloud for almost every workload there. Yes, there are exceptions; we don't tend to do a whole lot with them.And the government procurement process is a beast. We can sell and service three to five commercial engagements in the time it takes to negotiate a single GovCloud agreement with a customer, so it just isn't something that we focused. We don't have the scale to wind up tackling that down. Let's also be clear that, in many cases, governments don't view money the same way as enterprise, which in part is a good thing, but it also means that, “This cloud thing is too expensive,” is never the stated problem. Good question.“Waffles or pancakes?” Is another one. I… tend to go with eggs, personally. It just feels like empty filler in the morning. I mean, you could put syrup on anything if you're bold enough, so if it's just a syrup delivery vehicle, there are other paths to go.And I believe we might have exhausted the question pool. So, I want to thank you all for taking the time to talk with me. Once again, I am Cloud Economist Corey Quinn. And this is a very special live episode of Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review wherever you can—or a thumbs up, or whatever it is, like and subscribe obviously—whereas if you've hated this podcast, same thing: five-star review, but also go ahead and leave an insulting comment, usually around something I've said about a service that you deeply care about because it's tied to your paycheck.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
This week we're joined by Steve O'Grady, Principal Analyst & Co-founder at RedMonk. The topic today is the definition of open source, the constant pressure on the true definition of the term, and the seemingly small but vocal minority that aim to protect that definition. In Steve's post Why Open Source Matters, he says “open source is at a crossroads” and there are some seeking to break the definition of open source to one that is more permissive to their desires, and they are closer than ever to achieving that goal. Today's conversation goes deep on this subject.
This week we're joined by Steve O'Grady, Principal Analyst & Co-founder at RedMonk. The topic today is the definition of open source, the constant pressure on the true definition of the term, and the seemingly small but vocal minority that aim to protect that definition. In Steve's post Why Open Source Matters, he says “open source is at a crossroads” and there are some seeking to break the definition of open source to one that is more permissive to their desires, and they are closer than ever to achieving that goal. Today's conversation goes deep on this subject.
In this episode, we dive into the world of artificial intelligence (AI) and its impact on developer experience. James Governor of Redmonk joined us to explore the varying opinions on AI, from the fear of a robot takeover to the integration of AI in our daily lives. Tune in for a discussion on how AI is shaping the future of developers and how we can seek balance amidst rapid innovation. _To add emphasis to a point made in this episode: host Kat Gaines asked ChatGPT to write the first draft of our episode description. Three versions + her human edits later, she felt we had landed on something publishable._
How do you know whether what you are experiencing is bias, prejudice or bullying--or none of the above? Kim reads a story about an experience she had; guest Kate Holterhoff and co-host Wesley give her some feedback on the story. Then Kate shares a story about an experience she had. Come give it a listen and let us know what you think was going on there--bias, prejudice, bullying, or none of the above?About Kate Holterhoff: Kate completed her Ph.D. in literary and cultural studies at Carnegie Mellon in 2016; she is currently an analyst at RedMonk and an affiliated researcher at Georgia Tech.www.kateholterhoff.com/index.html
James Governor (@monkchips, Co-Founder @Redmonk) talks about Developer experience in 2023. Topics include trends, platforms, languages and culture.SHOW: 700CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwNEW TO CLOUD? CHECK OUT - "CLOUDCAST BASICS"SHOW SPONSORS:Make Cloud Native Ubiquitous with Cloud Native Computing Foundation (CNCF)Join the foundation of doers, CNCF is the open source, vendor-neutral hub of cloud native computing, hosting projects like Kubernetes and Prometheus to make cloud native universal and sustainableGitOpsCon + CDCon Registration Code: PODCAST10 for 10% offDatadog Security Solution: Modern Monitoring and SecurityStart investigating security threats before it affects your customers with a free 14 day Datadog trial. Listeners of The Cloudcast will also receive a free Datadog T-shirt.Solve your IAM mess with Strata's Identity Orchestration platformHave an identity challenge you thought was too big, too complicated, or too expensive to fix? Let us solve it for you! Visit strata.io/cloudcast to share your toughest IAM challenge and receive a set of AirPods ProSHOW NOTES:Redmonk - The developer focused analyst firm (homepage)Redmonk Programming Language RankingsMonktoberfest - Developer Conference (Portland, ME)Topic 1 - Welcome back to the show. You are a rockstar in the developer world, and maybe unknown in the infrastructure world. Tell us a little bit about your background.Topic 2 - [Developers as a Whole] In 2023, do you think about developers any differently than you did in 2018 or 2021? Do you think about developers in terms of things they get done, or the types of work they do (front-end, back-end, mobile, data-science, etc.), or something else?Topic 3 - [Trends] What are the big developer-centric trends that you are tracking or really have your interest? AI? Hosting services? Database services? WASM? Topic 4 - [Platforms] Will we ever find that PaaS pot-of-golf at the end of the rainbow, or is the dream of platforms just a unicorn? Or do we have to realize that successful platforms are all micro-platforms? Topic 5 - [Languages] Redmonk famously tracks development languages every six months. It feels like there are only two trends - what stays the same, and the language that is the new hotness. Do languages really matter? Topic 6 - [Culture] Lots of people talk about changing a company's culture to better serve the needs of developers. Do you have any examples of where that has worked, or best practices? FEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet
Incident response is the action taken to detect, triage, analyse, and remediate problems in software with the ultimate goal of minimising damage and restoring normal business functionality as quickly as possible. A well-executed incident response plan can help organisations mitigate the impact of security incidents and maintain the trust of their customers and stakeholders, but how specifically can the efficacy of an incident response program be assessed?In this episode of the EM360 Podcast, RedMonk analyst Kate Holterhoff spoke to Fred Hebert, Staff Site Reliability Engineer at Honeycomb, as they explore:Why some metrics are better than othersLessons we learn from fighting forest firesIncident response methodology
About ChrisChris is a mostly-backend mostly-engineer at Remix Labs, working on visual app development. He has been in software startups for ten years, but his first and unrequited love was particle physics. Before joining Remix Labs, he wrote numerical simulation and analysis tools for the Large Hadron Collider, then co-founded Roobiq, a clean and powerful mobile client for Salesforce back when the official ones were neither.Links Referenced: Remix Labs: https://remixlabs.com/ Twitter: https://twitter.com/chrisvermilion TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Tailscale SSH is a new, and arguably better way to SSH. Once you've enabled Tailscale SSH on your server and user devices, Tailscale takes care of the rest. So you don't need to manage, rotate, or distribute new SSH keys every time someone on your team leaves. Pretty cool, right? Tailscale gives each device in your network a node key to connect to your VPN, and uses that same key for SSH authorization and encryption. So basically you're SSHing the same way that you're already managing your network. So what's the benefit? Well, built-in key rotation, the ability to manage permissions as code, connectivity between any two devices, and reduced latency. You can even ask users to re-authenticate SSH connections for that extra bit of security to keep the compliance folks happy. Try Tailscale now - it's free forever for personal use.Corey: This episode is sponsored by our friends at Logicworks. Getting to the cloud is challenging enough for many places, especially maintaining security, resiliency, cost control, agility, etc, etc, etc. Things break, configurations drift, technology advances, and organizations, frankly, need to evolve. How can you get to the cloud faster and ensure you have the right team in place to maintain success over time? Day 2 matters. Work with a partner who gets it - Logicworks combines the cloud expertise and platform automation to customize solutions to meet your unique requirements. Get started by chatting with a cloud specialist today at snark.cloud/logicworks. That's snark.cloud/logicworksCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. When I was nine years old, one of the worst tragedies that can ever befall a boy happened to me. That's right, my parents moved me to Maine. And I spent the next ten years desperately trying to get out of the state.Once I succeeded and moved to California, I found myself in a position where almost nothing can drag me back there. One of the exceptions—basically, the only exception—is Monktoberfest, a conference put on every year by the fine folks at RedMonk. It is unquestionably the best conference that I have ever been to, and it continually amazes me every time I go. The last time I was out there, I met today's guest. Chris Vermilion is a Senior Software Developer at Remix Labs. Chris, now that I finished insulting the state that you call home, how are you?Chris: I'm great. I'm happy to be in a state that's not California.Corey: I hear you. It's, uh—I talk a lot of smack about Maine. But to be perfectly direct, my problem with it is that I grew up there and that was a difficult time in my life because I, really I guess, never finished growing up according to most people. And all right, we'll accept it. No one can hate a place in the same way that you can hate it if you grew up there and didn't enjoy the experience.So, it's not Maine that's the problem; it's me. I feel like I should clarify that I'm going to get letters and people in Maine will write those letters and then have to ride their horses to Massachusetts to mail them. But we know how that works.Chris: [laugh].Corey: So, what is Remix Labs? Let's start there. Because Remix sounds like… well, it sounds like a term that is overused. I see it everywhere in the business space. I know there was a Remix thing that recently got sold to I think it was at Shopify or Spotify; I keep getting those two confused. And—Chris: One of the two, yeah.Corey: Yeah, exactly one of them plays music and one of them sells me things except now I think they both do both, and everything has gone wonky and confusing. But what do you folks do over there?Chris: So, we work on visual app development for everybody. So, the goal is to have kind of a spreadsheet-on-steroids-like development environment where you can build interactively, you have live coding, you have a responsive experience in building interactive apps, websites, mobile apps, a little bit of everything, and providing an experience where you can build systems of engagement. So tools, mobile apps, that kind of work with whatever back-end resources you're trying to do, you can collaborate across different people, pass things around, and you can do that all with a nice kind of visual app developer, where you can sort of drop nodes around and wire them together and built in a way that's it's hopefully accessible to non-developers, to project managers, to domain experts, to you know, whatever stakeholders are interested in modifying that final product.Corey: I would say that I count as one of those. I use something similar to build the tool that assembles my newsletter every week, and that was solving a difficult problem for me. I can write back-ends reasonably well, using my primary tool, which is sheer brute force. I am not much of a developer, but it turns out that with enough enthusiasm, you can overcome most limitations. And that's great, but I know nothing about front end; it does not make sense to me, it does not click in the way that other things have clicked.So, I was fourth and inches from just retaining a contractor to build out a barely serviceable internal app. And I discovered, oh, use this low-code tool to drag and drop things and that basically was Visual Basic for internal apps. And that was awesome, but they're still positioned squarely in the space of internal apps only. There's no mobile app story, there's—and it works well enough for what I do, but I have other projects, I want to wind up getting out the door that are not strictly for internal use that would benefit from being able to have a serviceable interface slapped onto. It doesn't need to be gorgeous, it doesn't need to win awards, it just needs to be, “Cool, it can display the output of a table in a variety of different ways. It has a button and when I click a button, it does a thing, generally represented as an API call to something.”And doesn't take much, but being able to have something like that, even for an internal app, has been absolutely transformative just for workflow stuff internally, for making things accessible to people that are not otherwise going to be able to do those sorts of things, by which I mean me.Chris: Yeah. I mean, exactly, I think that is the kind of use case that we are aiming for is making this accessible to everybody, building tools that work for people that aren't necessarily software developers, they don't want to dive into code—although they can if they want, it's extensible in that way—that aren't necessarily front-end developers or designers, although it's accessible to designers and if you want to start from that end, you can do it. And it's amenable to collaboration, so you can have somebody that understands the problem build something that works, you can have somebody that understands design build something that works well and looks nice, and you can have somebody that understands the code or is more of a back-end developer, then go back in and maybe fine-tune the API calls because they realize that you're doing the same thing over and over again and so there's a better way to structure the lower parts of things. But you can pass around that experience between all these different stakeholders and you can construct something that everybody can modify to sort of suit their own needs and desires.Corey: Many years ago, Bill Clinton wound up coining the phrase, ‘The Digital Divide' to talk about people who had basically internet access and who didn't—those who got it or did not—and I feel like we have a modern form of that, the technology haves and have nots. Easy example of this for a different part of my workflow here: this podcast, as anyone listening to it is probably aware by now, is sponsored by awesome folks who wind up wanting to tell you about the exciting services or tools or products that they are building. And sometimes some of those sponsors will say things like, “Okay, here's the URL I want you to read into the microphone during the ad read,” and my response is a polite form of, “Are you serious?” It's seven different subdirectories on the web server, followed by a UTM series of tracking codes that, yeah, I promise, none of you are going to type that in. I'm not even going to wind up reading into the microphone because my attention span trips out a third of the way through.So, I needed a URL shortener. So, I set up snark.cloud for this. For a long time, that was relatively straightforward because I just used an S3 bucket with redirect objects inside of it. But then you have sort of the problem being a victim of your own success, to some extent, and I was at a point where, oh, I can have people control some of these things that aren't me; I don't need to be the person that sets up the link redirection work.Yeah, the challenge is now that you have a business user who is extraordinarily good at what he does, but he's also not someone who has deep experience in writing code, and trying to sit here and explain to him, here's how to set up a redirect object in an S3 bucket, like, why didn't I save time and tell him to go screw himself? It's awful. So, I've looked for a lot of different answers for this, and the one that I found lurking on GitHub—and I've talked about it a couple of times, now—runs on Google Cloud Run, and the front-end for that of the business user—which sounds ridiculous, but it's also kind of clever, is a Google Sheet. Because every business user knows how to work a Google Sheet. There's one column labeled ‘slug' and the other one labeled ‘URL' that it points to.And every time someone visits a snark.cloud slash whatever the hell the slug happens to be, it automatically does a redirect. And it's glorious. But I shouldn't have to go digging into the depths of GitHub to find stuff like that. This feels like a perfect use case for a no-code, low-code tool.Chris: Yeah. No, I agree. I mean, that's a cool use case. And I… as always, our competitor is Google Sheets. I think everybody in software development in enterprise software's only real competitor is the spreadsheet.Corey: Oh, God, yes, I wind up fixing AWS bills for a living and my biggest competitor is always Microsoft Excel. It's, “Yeah, we're going to do it ourselves internally,” is what most people do. It seems like no matter what business line I've worked in, I've companies that did Robo-advising for retirement planning; yeah, some people do it themselves in Microsoft Excel. I worked for an expense reporting company; everyone does that in Microsoft Excel. And so, on and so forth.There are really very few verticals where that's not an option. It's like, but what about a dating site? Oh, there are certain people who absolutely will use Microsoft Excel for that. Personally, I think it's a bad idea to hook up where you VLOOKUP but what do I know?Chris: [laugh]. Right, right.Corey: Before you wound up going into the wide world of low-code development over at Remix, you—well, a lot of people have different backstories when I talk to them on this show. Yours is definitely one of the more esoteric because the common case and most people talk about is oh, “I went to Stanford and then became a software engineer.” “Great. What did you study?” “Computer Science,” or something like it. Alternately, they drop out of school and go do things in their backyard. You have a PhD in particle physics, is it?Chris: That's right. Yeah.Corey: Which first, is wild in his own right, but we'll get back to that. How did you get here from there?Chris: Ah. Well, it's kind of the age-old story of academia. So, I started in electrical engineering and ended up double majoring in physics because that you had to take a lot of physics to be an engineer, and I said, you know, this is more fun. This is interesting. Building things is great, but sitting around reading papers is really where my heart's at.And ended up going to graduate school, which is about the best gig you can ever get. You get paid to sit in an office and read and write papers, and occasionally go out drinking with other grad students, and that's really about it.Corey: I only just now for the first time in my life, realized how much some aspects of my career resemble being a [laugh] grad student. Please, continue.Chris: It doesn't pay very well is the catch, you know? It's very hard to support a lifestyle that exists outside of your office, or, you know, involves a family and children, which is certainly one downside. But it's a lot of fun and it's very low stress, as long as you are, let's say, not trying to get a job afterward. Because where this all breaks down is that, you know, as I recall, the time I was a graduate student, there were roughly as many people graduating as graduate students every year as there were professors total in the field of physics, at least in the United States. That was something like the scale of the relationship.And so, if you do the math, and unfortunately, we were relatively good at doing math, you could see, you know, most of us were not going to go on, you know? This was the path to becoming a professor, but—Corey: You look at number of students and the number of professorships available in the industry, I guess we'll call it, and yeah, it's hmm, basic arithmetic does not seem like something that anyone in that department is not capable of doing.Chris: Exactly. So, you're right, we were all I think, more or less qualified to be an academic professor, certainly at research institutions, where the only qualification, really, is to be good at doing research and you have to tolerate teaching students sometimes. But there tends to be very little training on how to do that, or a meaningful evaluation of whether you're doing it well.Corey: I want to dive into that a bit because I think that's something we see a lot in this industry, where there's no training on how to do a lot of different things. Teaching is one very clear example, another one is interviewing people for jobs, so people are making it up as they go along, despite there being decades and decades of longitudinal studies of people figuring out what works and what doesn't, tech his always loved to just sort of throw it all out and start over. It's odd to me that academia would follow in similar patterns around not having a clear structure for, “Oh, so you're a grad student. You're going to be teaching a class. Here's how to be reasonably effective at it.” Given that higher education was not the place for me, I have very little insight into this. Is that how it plays out?Chris: I don't want to be too unfair to academia as a whole, and actually, I was quite lucky, I was a student at the University of Washington and we had a really great physics education group, so we did actually spend a fair amount of time thinking about effective ways to teach undergraduates and doing this great tutorial system they had there. But my sense was in the field as a whole, for people on the track to become professors at research institutions, there was typically not much in the way of training as a teacher, there was not really a lot of thought about pedagogy or the mechanics of delivering lectures. You know, you're sort of given a box full of chalk and a classroom and said, you know, “You have freshman physics this quarter. The last teacher used this textbook and it seems to be okay,” tended to be the sort of preparation that you would get. You know, and I think it varies institution to institution what kind of support you get, you know, the level of graduate students helping you out, but I think in lots of places in academia, the role of professors as teachers was the second thought, you know, if it was indeed thought at all.And similarly, the role of professors as mentors to graduate students, which, you know, if anything, is sort of their primary job is guiding graduate students through their early career. And again, I mean, much like in software, that was all very ad hoc. You know, and I think there are some similarities in terms of how academics and how tech workers think of themselves as sort of inventing the universe, we're at the forefront, the bleeding edge of human knowledge, and therefore because I'm being innovative in this one particular aspect, I can justify being innovative in all of them. I mean, that's the disruptive thing to do, right?Corey: And it's a shame that you're such a nice person because you would be phenomenal at basically being the most condescending person in all of tech if you wanted to. Because think about this, you have people saying, “Oh, what do you do?” “I'm a full-stack engineer.” And then some of the worst people in the world, of which I admit I used to be one, are, “Oh, full-stack. Really? When's the last time you wrote a device driver?”And you can keep on going at that. You work in particle physics, so you're all, “That's adorable. Hold my tea. When's the last time you created matter from energy?” And yeah, and then it becomes this the—it's very hard to wind up beating you in that particular game of [who'd 00:15:07] wore it better.Chris: Right. One of my fond memories of being a student is back when I got to spend more time thinking about these things and actually still remembered them, you know, in my electoral engineering days and physics days, I really had studied all the way down from the particle physics to semiconductor physics to how to lay out silicon chips and, you know, how to build ALUs and CPUs and whatnot from basic transistor gates. Yeah, and then all the way up to, you know, writing compilers and programming languages. And it really did seem like you could understand all those parts. I couldn't tell you how any of those things work anymore. Sadly, that part of my brain has now taken up with Go's lexical scoping rules and borrow checker fights with Rust. But there was a time when I was a smart person and knew those things.Corey: This episode is sponsored in part by our friends at Strata. Are you struggling to keep up with the demands of managing and securing identity in your distributed enterprise IT environment? You're not alone, but you shouldn't let that hold you back. With Strata's Identity Orchestration Platform, you can secure all your apps on any cloud with any IDP, so your IT teams will never have to refactor for identity again. Imagine modernizing app identity in minutes instead of months, deploying passwordless on any tricky old app, and achieving business resilience with always-on identity, all from one lightweight and flexible platform.Want to see it in action? Share your identity challenge with them on a discovery call and they'll hook you up with a complimentary pair of AirPods Pro. Don't miss out, visit Strata.io/ScreamingCloud. That's Strata dot io slash ScreamingCloud.Corey: I want to go back to what sounded like a throwaway joke at the start of the episode. In seriousness, one of the reasons—at least that I told myself at the time—that I left Maine was that it was pretty clear that there was no significant, lasting opportunity in industry when I was in Maine. In fact, the girl that I was dating at the time in college graduated college, and the paper of record for the state, The Maine Sunday Telegram, which during the week is called The Portland Press Herald, did a front-page story on her about how she went to school on a pulp and paper scholarship, she was valedictorian in her chemical engineering class at the University of Maine and had to leave the state to get a job. And every year they would roll out the governor, whoever that happened to be, to the University of Maine to give a commencement speech that's, “Don't leave Maine, don't leave Maine, don't leave Maine,” but without any real answer to, “Well, for what jobs?”Now, that Covid has been this plague o'er the land that has been devastating society for a while, work-from-home has become much more of a cohesive thing. And an awful lot of companies are fully embracing it. How have you seen Maine change based upon that for one, and for another, how have you found that community has been developed in the local sense because there was none of that in Maine when I was there? Even the brief time where I was visiting for a conference for a week, I saw definite signs of a strong local community in the tech space. What happened? I love it.Chris: It's great. Yeah, so I moved to Maine eight years ago, in 2014. And yeah, I was lucky enough to pretty early on, meet up with a few of the local nerds, and we have a long-running Slack group that I just saw was about to turn nine, so I guess I was there in the early days, called Computers Anonymous. It was a spinoff, I think, from a project somebody else had started in a few other cities. The joke was it was a sort of a confessional group of, you know, we're here to commiserate over our relationships with technology, which all of us have our complaints.Corey: Honestly, tech community is more of a support group than most other areas, I think.Chris: Absolutely. All you have to do is just have name and technology and somebody will pipe up. “Okay, you know, I've a horror story about that one.” But it has over the years turned into, you know, a very active Slack group of people that meet up once a month for beers and chats with each other, and you know, we all know each other's kids. And when the pandemic hit, it was absolutely a lifeline that we were all sort of still talking to each other every day and passing tips of, you know, which restaurants were doing takeout, and you know which ones were doing takeout and takeout booze, and all kinds of local knowledge was being spread around that way.So, it was a lucky thing to have when that hit, we had this community. Because it existed already as this community of, you know, people that were remote workers. And I think over the time that I've been here, I've really seen a growth in people coming here to work somewhere else because it's a lovely place to live, it's a much cheaper place to live than almost anywhere else I've ever been, you know, I think it's pretty attractive to the folks come up from Boston or New York or Connecticut for the summer, and they say, “Ah, you know, this doesn't seem so bad to live.” And then they come here for a winter, and then they think, “Well, okay, maybe I was wrong,” and go back. But I've really enjoyed my time here, and the tools for communicating and working remotely, have really taken off.You know, a decade ago, my first startup—actually, you know, in kind of a similar situation, similar story, we were starting a company in Louisville, Kentucky. It was where we happen to live. We had a tech community there that were asking those same questions. “Why is anybody leaving? Why is everybody leaving?”And we started this company, and we did an accelerator in San Francisco, and every single person we talked to—and this is 2012—said, you have to bring the company to San Francisco. It's the only way you'll ever hire anybody, it's the only way you'll ever raise any money, this is the only place in the world that you could ever possibly run a tech company. And you know, we tried and failed.Corey: Oh, we're one of those innovative industries in the world. We've taken a job that can be done from literally anywhere that has internet access and created a land crunch on eight square miles, located in an earthquake zone.Chris: Exactly. We're going to take a ton of VC money and where to spend 90% of it on rent in the Bay Area. The rent paid back to the LPs of our VC funds, and the circle of life continues.Corey: Oh, yeah. When I started this place as an independent consultant six years ago, I looked around, okay, should I rent space in an office so I have a place where I go and work? And I saw how much it costs to sublet even, like, a closed-door office in an existing tech startup's office space, saw the price tag, laughed myself silly, and nope, nope, nope. Instead installed a door on my home office and got this place set up as a—in my spare room now is transformed into my home office slash recording studio. And yeah, “Well, wasn't it expensive to do that kind of stuff?” Not compared to the first three days of rent in a place like that it wasn't. I feel like that's what's driving a lot of the return to office stories is the sort of, I guess, an expression of the sunk cost fallacy.Chris: Exactly. And it's a variation of nobody ever got fired for choosing IBM, you know? Nobody ever got fired for saying we should work in the office. It's the way we've always done things, people are used to it, and there really are difficulties to collaborating effectively remotely, you know? You do lose something with the lack of day-to-day contact, a lack of in-person contact, people really do get kind of burned out on interacting over screens. But I think there are ways around that and the benefits, in my mind, my experience, you know, working remotely for the last ten years or so, tend to outweigh the costs.Corey: Oh, yeah. If I were 20 years younger, I would absolutely have been much more amenable to staying in the state. There's a lot of things that recommend it. I mean, I don't want people listening to this to think I actually hate Maine. It's become a running joke, but it's also, there was remarkably little opportunity in tech back when I lived there.And now globally, I think we're seeing the rise of opportunity. And that is a line I heard in a talk once that stuck with me that talent is evenly distributed, but opportunity isn't. And there are paths forward now for folks who—I'm told—somehow don't live in that same eight-square miles of the world, where they too can build tech companies and do interesting things and work intelligently with other folks. I mean, the thing that always struck me as so odd before the pandemic was this insistence on, “Oh, we don't allow remote work.” It's, “Well, hang on a minute. Aren't we all telecommuting in from wherever offices happen to be to AWS?” Because I've checked thoroughly, they will not let you work from us-east-1. In fact, they're very strict on that rule.Chris: [laugh]. Yeah. And it's remarkable how long I think the attitude persisted that we can solve any problem except how to work somewhere other than SoMa.Corey: Part of the problem too in the startup space, and one of the things I'm so excited about seeing what you're doing over at Remix Labs, is so many of the tech startups for a long time felt like they were built almost entirely around problems that young, usually single men had in their 20s when they worked in tech and didn't want to deal with the inconveniences of having to take care of themselves. Think food delivery, think laundry services, think dating apps, et cetera, et cetera. It feels like now we're getting into an era where there's a lot of development and focus and funding being aimed at things that are a lot more substantial, like how would we make it possible for someone to build an app internally or externally without making them go to through a trial-by-fire hazing ritual of going to a boot camp for a year first?Chris: Yeah. No, I think that's right. I think there's been an evolution toward building tools for broader problems, for building tools that work for everybody. I think there was a definite startup ouroboros in the, kind of, early days of this past tech boom of so much money being thrown at early-stage startups with a couple of young people building them, and they solved a zillion of their own problems. And there was so much money being thrown at them that they were happy to spend lots of money on the problems that they had, and so it looked like there was this huge market for startups to solve those problems.And I think we'll probably see that dry up a little bit. So, it's nice to get back to what are the problems that the rest of us have. You know, or maybe the rest of you. I can't pretend that I'm not one of those startup people that wants on-demand laundry. But.Corey: Yet you wake up one day and realize, oh, yeah. That does change things a bit. Honestly, one of the weirdest things for me about moving to California from Maine was just the sheer level of convenience in different areas.Chris: Yes.Corey: And part of it is city living, true, but Maine is one those places where if you're traveling somewhere, you're taking a car, full stop. And living in a number of cities like San Francisco, it's, oh great, if I want to order food, there's not, “The restaurant that delivers,” it's, I can have basically anything that I want showing up here within the hour. Just that alone was a weird, transformative moment. I know, I still feel like 20 years in, that I'm “Country Boy Discovers City for the First Time; Loses Goddamn Mind.” Like, that is where I still am. It's still magic. I became an urban creature just by not being one for my formative years.Chris: Yeah. No, I mean, absolutely. I grew up in Ann Arbor, which is sort of a smallish college town, and certainly more urban than the areas around it, but visiting the big city of Detroit or Lansing, it was exciting. And, you know, I got older, I really sort of thought of myself as a city person. And I lived in San Francisco for a while and loved it, and Seattle for a while and loved it.Portland has been a great balance of, there's city; it's a five minute drive from my house that has amazing restaurants and concerts and a great art scene and places to eat and roughly 8000 microbreweries, but it's still a relatively small community. I know a lot of the people here. I sort of drive across town from one end to the other in 20 minutes, pick up my kids from school pretty easily. So, it makes for a nice balance here.Corey: I am very enthused on, well, the idea of growing community in localized places. One thing that I think we did lose a bit during the pandemic was, every conference became online, so therefore, every conference becomes the same and it's all the same crappy Zoom-esque experience. It's oh, it's like work with a slightly different topic, and for once the people on this call can't fire me… directly. So, it's one of those areas of just there's not enough differentiation.I didn't realize until I went back to Monktoberfest a month or so ago at the time at this call recording just how much I'd missed that sense of local community.Chris: Yeah.Corey: Because before that, the only conferences I'd been to since the pandemic hit were big corporate affairs, and yeah, you find community there, but it also is very different element to it, it has a different feeling. It's impossible to describe unless you've been to some of these community conferences, I think.Chris: Yeah. I mean, I think a smallish conference like that where you see a lot of the same people every year—credit to Steven, the whole RedMonk team for Monktoberfest—that they put on such a great show that every year, you see lots and lots of faces that you've seen the last several because everybody knows it's such a great conference, they come right back. And so, it becomes kind of a community. As I've gotten older a year between meetings doesn't seem like that long time anymore, so these are the friends I see from time to time, and you know, we have a Slack who chat from time to time. So, finding those ways to sort of cultivate small groups that are in regular contact and have that kind of specific environment and culture to them within the broader industry, I think has been super valuable, I think. To me, certainly.Corey: I really enjoyed so much of what has come out of the pandemic in some ways, which sounds like a weird thing to say, but I'm trying to find the silver linings where I can. I recently met someone who'd worked here with me for a year-and-a-half that I'd never met in person. Other people that I'd spoken to at length for the last few years in various capacity, I finally meet them in person and, “Huh. Somehow it never came up in conversation that they're six foot eight.” Like, “Yeah, okay/ that definitely is one of those things that you notice about them in person.” Ah, but here we are.I really want to thank you for spending as much time as you have to talk about what you're up to, what your experiences have been like. If people want to learn more, where's the best place for them to find you? And please don't say Maine.Chris: [laugh]. Well, as of this recording, you can find me on Twitter at @chrisvermilion, V-E-R-M-I-L-I-O-N. That's probably easiest.Corey: And we will, of course, put links to that in the [show notes 00:28:53]. Thank you so much for being so generous with your time. I appreciate it.Chris: No, thanks for having me on. This was fun.Corey: Chris Vermilion, Senior Software Developer at Remix Labs. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment, and since you're presumably from Maine when writing that comment, be sure to ask a grown-up to help you with the more difficult spellings of some of the words.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
Tom fell in love with computers and set up a software company while studying for a PhD in Plant Science in 1991. He has since worked for a number of companies at Global VP/CTO level. He recently left SAP after having been recruited in there in 2016 at Global VP level, where he worked as a Futurist, and Innovation Evangelist. Prior to that, he completed an almost eight year stint leading GreenMonk, the cleantech, energy and, sustainability practice of industry analyst firm RedMonk. Tom Raftery, Global VP, Futurist, and Innovation Evangelist --- https://tomraftery.com/ https://tomraftery.com/podcasts/ https://www.linkedin.com/in/tomraftery/ Host @ The Digital Supply Chain podcast --- https://www.digitalsupplychainpodcast.com/ The Digital Supply Chain podcast is a show hosted by Innovation Evangelist Tom Raftery, discussing thought leadership, best practices, and the latest innovations in delivering a resilient, sustainable supply chain. The show publishes a new episode every Monday and Friday, and features interviews with luminaries in the world of supply chain and Industry 4.0. All aspects of supply chains, and how to optimise them are discussed - everything from the design, planning, manufacturing, production, delivery, all the way through to product operation. On EP 055 Richard talks with Global VP, Futurist, and Innovation Evangelist Tom Raftery about: 00:00:33 : Meeting Tom Raftery. 00:09:34 : The power of podcasting in shaping the world narrative. 00:12:56 : Growing up in the 80s and 90s in Ireland. 00:18:31 : What's coming on the technology horizon. 00:23:29 : How supply chain has changed so much in the last three years. 00:29:21 : The convergence of supply chain and environmental best practices and how it will impact the future. 00:38:14 : How procurement has always been about cost, but as a strategic initiative, now it has to rethink through how am I disassembling this thing? 00:45:15 : What else is on the horizon for 3D printing? 00:51:51 : What's coming up for Tom in 2023.
DevRel has evolved over the past few years and in this podcast we are talking to the groundbreaking thought leaders who are paving the way for people and organizations who want to follow DevRel best practices. To many people, Developer Relations is the community management for technical audiences, but for others it's a lot more. It's building relationships and fostering trust, it's collecting and relaying feedback to other teams or it's inspiring people to build tools to empower.This week's guest is Kate Holterhoff, Analyst at RedMonkLinktree: https://www.linkedin.com/in/kateholterhoffTwitter: https://twitter.com/KateHolterhoffBlog: https://redmonk.com/kholterhoff
This week we give a little previous of what will be at the SpringOne conference, then cover some recent conferences. We then discuss the sudden emergence of "platform engineering" as a thing, and finish out by discussing what the kids are calling "FinOps," getting a handle on how much you're spending on cloud stuff. As always, with your pals @egrigson, @benbravo73, & @cote. Check out the livestream video if you like that kind of thing. Show Notes SpringOne Dec 6th and 8th. Check out the workshops and sessions. Escaping the Legacy Trap - Coté's talk with Marc. You can get the legacy trap booklet when you register for the webinar we did on the topic - also, watch the recording! Use the code COTE200 to get $200 off registration. News Conferences: Hashiconf announcements - RedMonk round-up. eBPF summit sessions are now online (it was 28th/29th Sept). Kong Summit. Platform Engineering Corner: boy, that's a thing now! Charity Major's piece. There was a whole conference. Paula has a good updated overview. Istio has joined the CNCF as incubating. Google published their 2022 Accelerate State of DevOps Report with lots of focus on security and platform-think. Surveys: Sysdig Threat Report. Buoyant's Service Mesh survey results. Cloud costs corner - Wan cloud report, PDF. Ben's new video “Deploy Your Python Apps To Production In Seconds”
This week we give a little previous of what will be at the SpringOne conference, then cover some recent conferences. We then discuss the sudden emergence of "platform engineering" as a thing, and finish out by discussing what the kids are calling "FinOps," getting a handle on how much you're spending on cloud stuff. As always, with your pals @egrigson, @benbravo73, & @cote. Check out the livestream video if you like that kind of thing. Show Notes SpringOne Dec 6th and 8th. Check out the workshops and sessions. Escaping the Legacy Trap - Coté's talk with Marc. You can get the legacy trap booklet when you register for the webinar we did on the topic - also, watch the recording! Use the code COTE200 to get $200 off registration. News Conferences: Hashiconf announcements - RedMonk round-up. eBPF summit sessions are now online (it was 28th/29th Sept). Kong Summit. Platform Engineering Corner: boy, that's a thing now! Charity Major's piece. There was a whole conference. Paula has a good updated overview. Istio has joined the CNCF as incubating. Google published their 2022 Accelerate State of DevOps Report with lots of focus on security and platform-think. Surveys: Sysdig Threat Report. Buoyant's Service Mesh survey results. Cloud costs corner - Wan cloud report, PDF. Ben's new video “Deploy Your Python Apps To Production In Seconds”
This week we discuss the rate of Public Cloud adoption, Google's Simplicity Sprint and OKR's. Plus, some thoughts on slippers. Watch the YouTube Live Recording of Episode 379. (https://www.youtube.com/watch?v=MEU1uSOpu-c) Runner-up Titles You're not proud of the product You can have both Landing Pages It's just like Serial Don't bring me these unqualified deals It's a Floppy Disk Problem The better the metrics, the less useful they are The sooner you are successful, the longer yoy'are successful Highly Edited Focus on Earnings Rundown AWS CEO says the move to cloud computing is only just getting started (https://www.cnbc.com/2022/06/28/aws-ceo-says-the-move-to-cloud-computing-is-only-just-getting-started.html) Acquired Episode on AWS (Podcast) (https://www.acquired.fm/episodes/amazon-web-services) Google and Developer Toil Google CEO Pichai tells employees not to 'equate fun with money' in heated all-hands meeting (https://www.cnbc.com/2022/09/23/google-ceo-pichai-fields-questions-on-cost-cuts-at-all-hands-meeting-.html) Google CEO tells employees productivity and focus must improve, launches 'Simplicity Sprint' to gather employee feedback on efficiency (https://www.cnbc.com/2022/07/31/google-ceo-to-employees-productivity-and-focus-must-improve.html) Google CEO tells staff not to 'equate fun with money' (https://www.theregister.com/2022/09/23/ceo_google_austerity/) Google CEO Pichai: We need to get 20% more productive (https://www.theregister.com/2022/09/07/google_ceo_sundar_pichai_productivity/) Relevant to your Interests PaaS Is Not Dead (https://www.fermyon.com/blog/paas-is-not-dead) How devops in the cloud breaks down (https://www.infoworld.com/article/3674690/how-devops-in-the-cloud-breaks-down.html) Adobe thinks critics are getting its Figma deal wrong (https://www.axios.com/newsletters/axios-login-c8c3c313-8144-4de3-9499-a4334a6b8f76.html?chunk=0&utm_term=emshare#story0) The Dead End from RedMonk (https://redmonk.com/sogrady/2022/09/23/dead-end/) Building for the 99% Developers (https://future.com/software-development-building-for-99-developers/) Meta and Google cut staff via quiet layoffs (https://www.theregister.com/2022/09/21/meta_google_layoffs/) Slack canvas has officially entered the chat! (https://twitter.com/slackhq/status/1572717714522705923?s=46&t=EYrb_JytmT9CVPWd_8-tpw) Linus Torvalds talks Rust on Linux, his work schedule and life with his M2 MacBook Air (https://www.zdnet.com/article/linus-torvalds-talks-rust-on-linux-his-work-schedule-and-life-with-his-m2-macbook-air/) Keynote: Frozen DevOps? The not-so-technical Last Mile (https://www.slideshare.net/ManuelPais/keynote-frozen-devops-the-notsotechnical-last-mile-devopsdays-portugal-sep-2022) Penpot inks $8M, as signups for its open source spin on Figma jump 5600% after Adobe's $20B acquisition (https://twitter.com/TechCrunch/status/1574754640490536963?s=20&t=vQF0s31OdAS2p7-X373AzQ) Document onboarding startup Flatfile nabs $50M from investors, including Workday (https://techcrunch.com/2022/09/27/document-onboarding-startup-flatfile-nabs-50m-from-investors-including-workday/) Suborbital Extension Engine, and what's next for us (https://blog.suborbital.dev/suborbital-extension-engine-and-whats-next-for-us) What's Stopping WebAssembly from Widespread Adoption? (https://thenewstack.io/whats-stopping-webassembly-from-widespread-adoption/) Did We Overeat on Software? (https://future.com/did-we-overeat-on-software/) Someone is pretending to be me. (https://connortumbleson.com/2022/09/19/someone-is-pretending-to-be-me/) Broadcom's Golden Parachute For Top 5 VMware Execs May Total $337.8M (https://www.crn.com/news/cloud/broadcom-s-golden-parachute-for-top-5-vmware-execs-may-total-337-8m/6) For teens to do better in school, they need to sleep in (https://fortune.com/well/2022/08/18/how-later-school-start-times-for-teens-reduce-depression-and-improve-academic-performance/) Leading venture capital firms to provide up to $1.25 BILLION to back startups built on Cloudflare Workers (https://blog.cloudflare.com/workers-launchpad/) The Uber Hack Exposes More †Than Failed Data Security (https://www.nytimes.com/2022/09/26/opinion/uber-hack-data.html?utm_source=newsletter&utm_medium=email&utm_campaign=newsletter_axioslogin&stream=top) Leading venture capital firms to provide up to $1.25 BILLION to back startups built on Cloudflare Workers (https://blog.cloudflare.com/workers-launchpad/) Nonsense The Science Behind NASA's First Attempt at Redirecting an Asteroid (https://www.jpl.nasa.gov/edu/news/2022/9/22/the-science-behind-nasas-first-attempt-at-redirecting-an-asteroid) Ghoulish moans are haunting the intercoms of American Airlines flights (https://www.washingtonpost.com/travel/2022/09/26/flight-noise-american-airlines-intercom-lax/) Podcasters Are Buying Millions of Listeners Through Mobile-Game Ads (https://www.bloomberg.com/news/articles/2022-09-27/inside-podcasters-explosive-audience-growth) Conferences Sydney Cloud FinOps Meetup (https://events.finops.org/events/details/finops-sydney-cloud-finops-presents-sydney-cloud-finops-meetup/), online, Oct 13, 2022 Matt's presenting KubeCon North America (https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/), Detroit, Oct 24 – 28, 2022 SpringOne Platform (https://springone.io/?utm_source=cote&utm_medium=podcast&utm_content=sdt), SF, December 6–8, 2022 THAT Conference Texas Call For Counselors (https://that.us/call-for-counselors/tx/2023/) Jan 16-19, 2023 Listener Feedback Happy to report that the world-class engineers at @grafana managed to make a @SlackHQ thread with more than 10,000 messages in it. (https://twitter.com/TwitchiH/status/1574522695399661584) SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Get a SDT Sticker! Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you free laptop stickers! Follow us on Twitch (https://www.twitch.tv/sdtpodcast), Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/), LinkedIn (https://www.linkedin.com/company/software-defined-talk/) and YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured). Use the code SDT to get $20 off Coté's book, (https://leanpub.com/digitalwtf/c/sdt) Digital WTF (https://leanpub.com/digitalwtf/c/sdt), so $5 total. Become a sponsor of Software Defined Talk (https://www.softwaredefinedtalk.com/ads)! Recommendations Brandon: Introducing PowerPoint Live in Microsoft Teams (https://techcommunity.microsoft.com/t5/microsoft-365-blog/introducing-powerpoint-live-in-microsoft-teams/ba-p/2140980) and/or PowerPoint Reading Mode (https://www.thinkoutsidetheslide.com/use-reading-view-to-show-powerpoint-slides-in-a-window-instead-of-full-screen/) Photo Credits Banner (https://unsplash.com/photos/B2Y0zdSbR8U) CoverArt (https://unsplash.com/photos/ij5_qCBpIVY)
Cet épisode marathon sera découpé en deux morceaux pour éviter à vos oreilles une écoute marathon. Dans cet épisode on y parle Brian Goetz, Bian Goetz, Brian Goetz, usages des threads virtuels, OpenAPI, Kubernetes, KNative, copilot et Tekton. La deuxième partie couvrira des sujets d'architecture et de loi société et organisation ainsi que les conférences à venir. Enregistré le 8 juillet 2022 Téléchargement de l'épisode LesCastCodeurs-Episode–281.mp3 News Langages Peut-être une nouvelle syntaxe spécifique aux Records Java pour tordre le cou aux builders Brian Goetz discute de l'idée d'avoir une syntaxe spécifique pour les records pour facilement créer un record dérivé, potentiellement avec des valeurs par défaut, mais en paramétrant certains champs Point shadowPos = shape.position() with { x = 0 } Cela évite de créer la notion de paramètre par défaut dans les constructeurs ou les méthodes Il y a l'article Data Oriented Programming de Brian Goetz, sur InfoQ projet Amber amène des changements qui combinés permet de faire du data oriented programming en Java et pas que du OOP OO combine état et comportement (code) OO est super utile pour défendre des limites (programme large en des limites plus petites et plus gérable) mais on s'oriente vers des applications plus petites (microservices) data oriented programming: modélise data immuable et le code de la logique métier est séparée records -> data en tant que classe, sealed classes -> définir des choix, pattern matching -> raisonne sur des data polymorphiques algebraic data: hiérarchie de sealed classes dont les feuilles sont des records: nommées, immuable, testable (pas de code) Un nouveau JEP pour intégrer une Classfile API Le JDK inclut déjà des forks de ASM, de BCEL, et d'autres APIs internes, pour manipuler / produire / lire le bytecode Mais l'idée ici c'est que le JDK vienne avec sa propre API officielle, et qui soit plus sympa à utiliser aussi que le pattern visiteur de ASM par exemple La version d'ASM intégrée était toujours en retard d'une version (problème de poule et d'oeuf, car ASM doit supporter la dernière version de Java, mais Java n+1 n'est pas encore sorti) Lilian nous montre à quoi va ressembler les Record Patterns de JEP 405 Apache Groovy et les virtual threads, et aussi Groovy et le Deep Learning Paul King, qui dirige actuellement le PMC de Apache Groovy, a partagé récemment plusieurs articles sur le blog d'Apache sur des intégrations intéressantes avec Groovy Groovy et sa librairie GPars pour la programmation concurrente et parallèle s'intègre facilement avec les Virtual Threads de JEP 425 / JDK 19 https://blogs.apache.org/groovy/entry/gpars-meets-virtual-threads Groovy avec Apache Wayang et Apache Spark pour classifier des Whiskey par clusterisation KMeans https://blogs.apache.org/groovy/entry/using-groovy-with-apache-wayang Et aussi Groovy avec différentes librairies de Deep Learning pour la classification https://blogs.apache.org/groovy/entry/classifying-iris-flowers-with-deep Le jargon (en anglais) de la programmation fonctionnelle, si vous avez rêvé d'avoir sous la main la définition de foncteur, de monoïde, et j'en passe avec des exemples en JavaScript des pointeurs vers des librairies fonctionnelles en JavaScript des traductions dans d'autres langues et d'autres langages de programmation Librairies Spring Boot 2.7 SpringBoot 2.7 Spring GraphQL 1.0 Support pour Podman Gestion de dépendance et auto configuration pour Cache2k nouvelle annotations pour Elasticsearch et CouchBase dernière versions avant SpringBoot 3 qui changera plus de choses. Recommande de migrer une version a la fois. Support pour 2.5 à fini (upstream) Quarkus 2.10.0 Travaux préliminaires sur les threads virtuels de Loom Support non-blocking pour GraphQL Prise en charge des Kubernetes service binding pour les clients SQL réactifs CacheKeyGenerator pour l'extension de cache quarkus-bootstrap-maven-plugin déprécié et remplacé par quarkus-extension-maven-plugin (uniquement utile pour les développeurs d'extensions Quarkus) Nouveaux guides: Using Stork with Kubernetes OpenId Connect Client Reference Guide Using Podman with Quarkus Les différences entre OpenAPI 2 et 3 Introduction de la notion de lien pour créer des relations entre Response et Operations, pratique pour faire des APIs hypermédia La structure du document OpenAPI a été -un peu simplifiée, en combinant par exemple basePath et schemes, ou en rassemblant les securityDefinitions Des améliorations sur les security schemes, autour de OAuth et OpenID Plus de clarté dans la négociation de contenu et les cookies La section des exemples de Request / Response devrait aider les outils qui génèrent par exemple des SDK automatiquement à partir de la description OpenAPI Un support étendu de JSON Schema Introduction d'une notion de Callback, importante pour les APIs asynchrones, en particulier les WebHooks je me demande si ils ont l'intention d'embrasser AsyncAPI ou su la partie asynchrone d'OpenAPI 3 a pour objectif de faire de la competition Infrastructure N'utilisez pas Kubernetes tout de suite ! Kubernetes, c'est bien, mais c'est un gros marteau. Est-ce que vous avez des gros clous à enfoncer ? Ne commencez peut-être pas avec l'artillerie lourde de Kubernetes. Commencez plutôt avec des solutions managées genre serverless, ce sera plus simple, et au fur et à mesure si votre infrastructure a besoin de grossir et dépasse les fonctionnalités des solutions managées, à ce moment là seulement évaluer si Kubernetes peut répondre à votre besoin Choisir Kubernetes, c'est aussi avoir la taille de l'équipe qui va bien avec, et il faut des profils DevOps, SRE, etc, pour gérer un cluster K8S L'auteur suggère grosso modo que ça dépend de l'ordre de magnitude de la taille de l'équipe : avec quelques personnes, préférez des solutions type Google App Engine ou AWS App Runner, avec une dizaine de personne peut-être du Google Cloud Run ou AWS Fargate, avec moins d'une centaine là pourquoi pas du Kubernetes managé comme Google Kubernetes Engine, et si vous dépassez mille, alors peut-être vos propres clusters managés par vos soins et hébergés par vos soins sur votre infra ca impose d'utiliser les services du cloud provider? Parce que la vie ce n'est pas que du code maison. C'est la mode de dire de pas utiliser K8S : https://www.jeremybrown.tech/8-kubernetes-is-a-red-flag-signalling-premature-optimisation/ (mais bon, vu le nombre de fois où il est pas utilisé à b Knative Eventing Devlivery methods on peut faire de la delviery simple 1–1 sans garantie on peut faire de la delivery complexe et persistante en introduisant la notion de channel qui decouple la source de la destination. on peut repondre a la reception d'un message et pousser la réponse dans un second channel mais ca devient compliquer a gérer quand on rajoute des souscripteurs il y a la notiuon de broker qui definit: des flitres, un channel (automatique) et la capacité de répondre les triggers sont un abonnement non pas a un channel mais a un type d'évènement spécifique Cloud AWS is Windows and Kube is Linux pourquoi utilisez Kube qui etait pas stablewa lors qu'AWS offre tout AWS forcé d'offrir EKS MAis pourri Lockin AWSIAM Pourquoi AWS serait le windows economies d'echelles de faire chez soi kube devient rentable une certaine taille de l'organisation besoin alternative a AWS (bus factor) on voit le Kube distro modele arriver Google data center Paris Outillage IntelliJ IDEA 2022.5 EAP 5 amène des nouveautés Frameworks and Technologies Spring 6 and Spring Boot 3 Support for new declarative HTTP Clients in Spring 6 URL completion and navigation for Spring Cloud Gateway routes Experimental GraalVM Native Debugger for Java Code insight improvements for JVM microservices test and mock frameworks Code insight improvements for Spring Shell Improved support for JAX-RS endpoints Support for WebSockets endpoints in HTTP Client Support for GraphQL endpoints in the HTTP Client UI/UX improvements for the HTTP Client Improved navigation between Protobuf and Java sources Kubernetes and Docker Intercept Kubernetes service requests with Telepresence integration Upload local Docker image to Minikube and other connections Docker auto-connection at IDE restart Docker connection options for different docker daemons GitHub copilot est disponible pour tous (les developpeurs) 40% du code écrit est généré par copilot en python (ca calme) gratuit pour les étudiants et les développeurs OSS Revue de Redmonk décrit copilot comme une extension d'intelligence ou auto complete mais qui « comprend » le code autour premiere fois pas une boite de cette taille et à cette échelle l'avantage de copilot en terme de productivité, de qualité de code, de sécurité et de légalité En gros, c'est encore à voir. Mais la qualité impressionne les gens qui l'ont testé ; sécurité pas de retour d'un côté ou de l'autre sauf que les développeurs humains ne sont pas des lumières de sécurité :D GitHub pense que GitHub n'est pas responsable de la violation de code vue que ce sont des machines et des algorithmes qui transforment: cela a l'air d'etre le consensus des avocats GitHub dit qu'on est responsable du code qu'on écrit avec copilot Et implicitement GitHub dit que la licensure du code « source » ne se propage pas au code generé. Et là, c'est pas clair et de la responsibilité de l'utilisateur, mais la encore les avocats sont plutot ok moralement c'est probablement pas ok mais bon et il y a débat autour des licenses copyleft notamment LGPL 1% du temps, code copié verbatim de > 150 caractères Question sur le code non open source sur lequel GitHub Copilot s'appuie mais en gros le marcher s'en fout un peu des licences Risque de reputation de Microsoft la question c'est quand / si les gens seront prêt à accepter cet usage Gradle publie sa roadmap Historiquement, la société Gradle Inc ne publiait pas vraiment de roadmap officielle Outre les tickets que l'on pouvait voir dans Github, cette fois ci, une “roadmap board” est visible et disponible pour tout le monde, et pas seulement pour les clients Tekton est groovy (mais non, il n'utilise pas Groovy !) Un grand tutoriel sur Tekton Une brève histoire de CI/CD (avec un contraste avec Groovy utilisé dans Jenkins) Un aperçu des grands concepts de Tekton, avec ses tâches et ses pipelines (Task, TaskRun, Pipeline, PipelineRun) Comment installer Tekton Les outils CLI Un exemple concret d'utilisation Sortie de Vim 9, surtout avec VimScript 9 des changements incompatibles entre VimScript 8.2 et 9 font qu'il était nécessaire de passer à une version majeure mais l'ancienne version du langage reste supportée pour compatibilité avec la nouvelle, les utilisateurs peuvent s'attendre à des performances x10 voire x100 ! le langage devient pré-compilé, au lieu d'être interprété ligne par ligne l'idée était d'avoir un langage plus proche de ce qu'on trouve dans JavaScript, TypeScript ou Java Conférences De la part de Youen Cette année Codeurs en Seine, c'est le 17 novembre et le cfp est ouvert N'hésitez pas à amener un peu de JVM dans l'appel à orateur. (ca commence à se faire rare). Pour rappel : codeurs en seine c'est 1000 personnes autour des métiers du développement dans une des plus grande salle de Rouen, le kindarena. Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/
Cet épisode une fois n'est pas coutume parle beaucoup de nouvelles dans la rubrique langage et beaucoup de Java, wouhou ! On parle aussi de sigstore, http/3, Micronaut et de VMWare. Enregistré le 10 juin 2022 Téléchargement de l'épisode LesCastCodeurs-Episode–280.mp3 News Langages Sept raisons pour lesquelles Java a a encore du sens après 26 ans communauté (dans toutes les grandes villes) force du langage et de la plateforme plus de problèmes résolus que non résolus (librairies) stabilité Innovation (Java 9 accélère l'innovation) outillage opportunité d'emploi Les débuts du projet Leyden Mark Reinhold lance le projet Leyden, pour adresser les problèmes de temps de démarrage lent de Java, de lenteur du temps jusqu'à la performance max, et d'empreinte un peu lourde à l'aide d'une image statique de votre application une image statique ne fait tourner qu'une seule et unique application sur son JDK, et est un “monde fermé” (ne peut pas charger de classe externes) mais les ingés de la JVM vont travailler sur une approche assez souple, et voire quelles contraintes peuvent être allégées, par rapport à un monde complètement fermé d'une image statique en espérant avoir des améliorations à différents niveaux, pour un max d'appli et de use case différents Le close world c'est ce qui amène la valeur de GraalVM native image et les avantages pour Micronaut, Quarkus et le autres donc pas de closed world: c'est encore un projet de recherche pour l'équipe de la JVM JFR plus facile à configuer dans Java 17 un wizard en UI ou CLI pour generer le fichier .jfc Proposition de structured concurrency via le projet Loom Targeted status for JDK 19. This incubating JEP, under the auspices of Project Loom, proposes to simplify multithreaded programming by introducing a library to treat multiple tasks running in different threads as a single unit of work. This can streamline error handling and cancellation, improve reliability, and enhance observability RedMonk analyse l'apparition du langage Dart, grâce à Flutter, dans leur top 20 des langages de programmation les plus populaires JavaScript, Python, Java, toujours en tête Mais Rust et Dart sont rentrés récemment L'arrivée de Dart coïncide surtout avec l'émergence de Flutter comme framework d'interface graphique, que ce soit pour Android/iOS, que pour le desktop et le web Sur les applis mobiles, il y a toujours eu beaucoup de développement natif, mais est aussi arrivé React Native, mais aussi Flutter Des applis de Google comme Google Pay et Google Ads sont développées en Flutter, mais aussi le récent SNCF Connect ou des entreprises telles que BMW ou Alibaba (modifié) (cf le talk sur le REX par les développeurs de SNCF Connect à Devoxx France) les investissements initiaux de Dart vs Kotlin ou Ceylon qui ont démarrés en meme temps étaient colossaux Dart en natif pour faire des applis iOS… qui tournent aussi sous Android Kotlin 1.7 est sorti Kotlin K2 compiler pour la JVM em Alpha (les plug ins ne fonctionne pas) amélioration des perf de Kotlin et du compilo pour la JVM build incremental Gradle annotation OptIn et inférence de Builder stabilisés classes implementee par delegation automatique sans consommation mémoire (via inlining) Librairies Sortie de Micronaut 3.5 Passage à GRAALVM 22.1.0 Compilation incrémentale lors des builds, en particulier intéressant pour les métadonnées pour GraalVM, ce qui permet d'éviter de faire tourner les processeurs d'annotation inutilement Inclusion de Micronaut Data 3.4, avec support des enums Postgres pour JDBC, la pagination pour les Reactive Repositories Intégration avec Turbo pour la vue (Turbo Frame et Turbo Views) Nouveau module pour MicroStream (un moteur de graphe d'objet natif Java, intégré à Helidon) Mise à jour de nombreux plugins et extensions (y compris plugins de build) Infrastructure Kubernetes signals massive adoption of Sigstore for protecting open source ecosystem Kubernetes 1.24 (sorti en mai) est la première version utilisant officiellement Sigstore, permettant une vérification transparente des signatures pour protéger contre les attaques de la chaîne d'approvisionnement Sigstore est une nouvelle norme pour la signature, la vérification et la protection des logiciels. Elle se veut être un remplaçant pour GPG par exemple. Sigstore offre une variété d'avantages à la communauté Kubernetes comme: Sigstore's keyless signing donne une grande expérience de développeur et supprime le besoin de la gestion de clé douloureuse. Le journal public et transparent de Sigstore (Rekor) avec ses API permettent aux consommateurs Kubernetes de vérifier les signatures. … Web RFC 9114 - HTTP/3 est validée (+ RFC 9204 - QPACK: Field Compression for HTTP/3 et RFC 9218 - Extensible Prioritization Scheme for HTTP) Basé sur le protocole de transport QUIC qui possède plusieurs fonctionnalités intéressantes telles que le multiplexage de flux, le contrôle de flux par flux et l'établissement de connexion à faible latence. QPACK : un format de compression pour représenter efficacement les champs HTTP à utiliser en HTTP/3. Il s'agit d'une variation de la compression HPACK qui vise à réduire la taille des headers. Extensible Prioritization Scheme for HTTP: schéma qui permet à un client HTTP de communiquer ses préférences quant à la façon dont le serveur en amont priorise les réponses à ses demandes, et permet également à un serveur d'indiquer à un intermédiaire en aval comment ses réponses devraient être priorisées lorsqu'elles sont transmises. Outillage VSCode Java 1.5 est sorti Java 18 support, inlay hints for method parameters, and improvements to class declaration navigation are just a few of the enhancements to expect. Architecture L'architecture Netflix Pas fou fou dans les infos mais ça fait longtemps qu'on a pas eu d'archi analyze the system design in terms of availability, latency, scalability and resilience to network failure basé sur AWS clients via un SDK est intelligent, contrôle le backend utilisé et la bande passante en temps réel Open Connect CDN: là ou les vidéos sont stockées le reste du bon vieux microservice en backend ramène les dix meilleurs points d'accès et le client choisi voire change API Gateway via Zuul: dynamic routing, traffic monitoring and security, resilience to failures at the edge of the cloud deployment etc Loi, société et organisation VMWare racheté par Broadcom 61 milliards de dollars Avec un objectif de passer de 3,5 à 8,5 milliard d'EBITA par an Bouger dans la division cloud avec Symantec VMWare était content de sa liberté retrouvée après la spin off de Dell Apparemment pas d'alignement de tech une expansion de portefeuiille dans le software pour broadcom VMWare a beaucoup changé de mains ces dernières années La strategie d'investissement de broadcom: acheter des franchises avec une bonne position de marcher et un potentiel de profitabilité augmenté sans gros investissements La rumeur un ex de VMWare qui pense que c'est la mort de VMWare Outils de l'épisode GitHub Copilot quand le code s'écrit tout seul … (en fait non, les développeurs ont encore des beaux jours devant eux) A voir aussi: Github Co-Pilot : Addictif ou Efficace ? (Johan Jublanc et Simon Provost) à Devoxx France 2022 Rubrique débutant Conférences Source: Developers Conferences Agenda/List by Aurélie Vache et contributeurs June 14: France API - Paris (France) 15–18: VIVA Technology - Paris (France) 17: Cloud Ouest 2022 - Nantes (FR) + Online 21–22: Voxxed Days Luxembourg - Luxembourg 23: ServerlessDays Paris - Paris (France) 24: SoCraTes Rennes - Rennes (France) 27–1: Hack in Paris - Paris (France) 28: Dev nation Day France - Paris (France) 29–1: BreizhCamp - Rennes (France) 30–1: Sunny Tech - Montpellier (France) 30–1: Agi'Lille 2022 - Lille (France) September 9: JUG SummerCamp - La Rochelle (France) 29: Cloud Nord - Lille (France) October 4–6: Devoxx Morocco - Agadir (Morocco) 6–7: Paris Web - Paris (France) 10–14: Devoxx Belgium - Antwerp (Belgium) 13–14: Volcamp 2022 - Clermont Ferrand (France) 20–21: DevFest Nantes - Nantes (France) 27–28: Agile Tour Bordeaux - Bordeaux (France) November 8–9: Open Source Experience - Paris (France) 15–16: ParisTestConf - Online 15–16: Agile Tour Toulouse - Toulouse (France) 17: Codeurs en Seine - Rouen (France) 18: Devfest Strasbourg - Strasbourg (France) 19–20: Capitole du Libre - Toulouse (France) December 1: Devops DDay #7 - Marseille (France) 2: BDX I/O - Bordeaux (France) 14–16: API Days Paris - Paris (France) & Online Nom de la conf du x au y mois à Ville - CfP jusqu'à y mois TODO: reprendre celles de l'épisode d'avant Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/
About KateKate Holterhoff, an industry analyst with RedMonk, has a background in frontend engineering, academic research, and technical communication. Kate comes to RedMonk from the digital marketing sector and brings with her expertise in frontend engineering, QA, accessibility, and scrum best practices.Before pursuing a career in the tech industry Kate taught writing and communication courses at several East Coast universities. She earned a PhD from Carnegie Mellon in 2016 and was awarded a postdoctoral fellowship (2016-2018) at Georgia Tech, where she is currently an affiliated researcher.Links: RedMonk: https://redmonk.com/ Visual Haggard: https://visualhaggard.org Twitter: https://twitter.com/kateholterhoff TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Couchbase Capella Database-as-a-Service is flexible, full-featured, and fully managed with built-in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price-performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: Make your data sing.Corey: This episode is sponsored by our friends at Revelo. Revelo is the Spanish word of the day, and its spelled R-E-V-E-L-O. It means, “I reveal.” Now, have you tried to hire an engineer lately? I assure you it is significantly harder than it sounds. One of the things that Revelo has recognized is something I've been talking about for a while, specifically that while talent is evenly distributed, opportunity is absolutely not. They're exposing a new talent pool to, basically, those of us without a presence in Latin America via their platform. It's the largest tech talent marketplace in Latin America with over a million engineers in their network, which includes—but isn't limited to—talent in Mexico, Costa Rica, Brazil, and Argentina. Now, not only do they wind up spreading all of their talent on English ability, as well as you know, their engineering skills, but they go significantly beyond that. Some of the folks on their platform are hands down the most talented engineers that I've ever spoken to. Let's also not forget that Latin America has high time zone overlap with what we have here in the United States, so you can hire full-time remote engineers who share most of the workday as your team. It's an end-to-end talent service, so you can find and hire engineers in Central and South America without having to worry about, frankly, the colossal pain of cross-border payroll and benefits and compliance because Revelo handles all of it. If you're hiring engineers, check out revelo.io/screaming to get 20% off your first three months. That's R-E-V-E-L-O dot I-O slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while on the Twitters, I see a glorious notification. Now, doesn't happen often, but when it does, I have all well, atwitter, if you'll pardon the term. They have brought someone new in over at RedMonk.RedMonk has been a longtime friend of the show. They're one of the only companies that can say that about and not immediately get a cease-and-desist for having said that. And their most recent hire is joining me today. Kate Holterhoff is a newly minted analyst over at RedMonk. Kate, thank you for joining me.Kate: It's great to be here.Corey: One of the things that's always interesting about RedMonk is how many different directions you folks seem to go in all at once. It seems that I keep crossing paths with you folks almost constantly: When I'm talking to clients, when I'm talking to folks in the industry. And it could easily be assumed that you folks are 20, 30, 40 people, but to my understanding, there are not quite that many of you there.Kate: That is very true. Yes. I am the fifth analyst on a team of seven. And yeah, brought on the first of the year, and I'm thrilled to be here. I actually, I would say, recruited by one of my friends at Georgia Tech, Kelly Fitzpatrick, who I taught technical communication with when we were both postdocs in their Brittain Fellowship program.Corey: So, you obviously came out of an academic background. Is this your first excursion to industry?Kate: No, actually. After getting my PhD in literary and cultural studies at Carnegie Mellon in 2016, I moved to Atlanta and took a postdoc at Georgia Tech. And after that was kind of winding down, I decided to make the jump to industry. So, my first position out of that was at a digital marketing agency in Atlanta. And I was a frontend engineer for several years.Towards the end of my tenure there, I moved into doing more of their production engineering and QA work. Although it was deeply tied to my frontend work, so we spent a lot of time looking at how the web sites look at different media queries, making sure that there were no odd break points. So, it certainly was an organic move there as their team expanded.Corey: You spent significant amounts of time in the academic landscape. When you start talking about, “Well, I took on a postdoc position,” that's usually the sign of not your first year on a college campus in most cases. I mean, again, with an eighth grade education, I'm not really the person to ask, but I sit here in awe as people who are steeped in academia wind up going about the magic that, from where I sit, they tend to do. What was it that made you decide that I really enjoy the field that I've gotten a doctorate in. You just recently published a book in that is—or at least tangentially related to this space.But you decide, “You know what I really want to do now? That's right, frontend engineering. I want to spend, more or less, 40-some-odd hours a week slowly going mad because CSS, and I can't quite get that thing to line up the way that I want it to.” Now, at least that's my experience with it, for folks who are, you know, competent at it, I presume that's a bit of a different story.Kate: Yes. I considered naming my blog at RedMonk, “How to Center a Div.” So yes, that is certainly an ongoing issue, I think, for anyone in [unintelligible 00:06:15] any, you know, practitioners. So, I guess my story probably began in 2013, the real move into technology. So, getting a PhD, of course, takes a very, very long time.So, I started at Carnegie Mellon in 2009, and in 2013, I started a digital archive called Visual Haggard. And it's a Ruby on Rails site; you can visit it at visualhaggard.org. And it is a digital archive of illustrations that were created to accompany a 19th century writer, H. Rider Haggard.And I became very interested in all the illustrations that had been created to accompany both the serialization of his fictions, but also the later novelizations. And it's kind of like how we have all these different movie adaptations of, like, Spider Man that come out every couple of years. These illustrations were just very iterative. And generally, this fellowship that I saw really only focused on, you know, the first illustrations that, you know, came out. So, this was a sort of response to that: How can we use technology to showcase all the different types of illustrations and how maybe different artists would interpret that literature differently?And so, that drove me into a discipline called the digital humanities, which really sort of, you know, focuses on that question, which is, you know, how to computers help us to understand the humanities better? And so, that incorporates not only the arts, but also literature, philosophy, you know, new media. But it's an extremely broad subject, and it's evolving, as you can imagine, as the things that technology can do expands. So, I became interested in this subject and really was drawn to the sort of archival aspects of this. Which wasn't really my training; I think that's something that, you know, you think of librarians as being more focused on, but I became acquainted with all these, you know, very obscure editions.But in any event, it also taught me how to [laugh] use technology, I really—I was involved in the [RDF 00:08:08] export for [laugh] incorporating the site on Nines, which is sort of a larger agglomeration of 19th century archives. And I was just really drawn to a lot of the new things that we could do. So, I began to use it more in my teaching. So, not only did I—and of course as I taught communication courses at Carnegie Mellon, and then I moved to teaching them at Georgia Tech, you can imagine I had many students who were engineers, and they were very interested in these sorts of questions as well. So, the move felt very organic to me, but I think any academic that you speak to, their identity is very tied up in their sort of, you know, academic standing.And so, the idea of jumping ship, of not being labeled an academic anymore is kind of terrifying. But I, you know, ultimately opted to do it. It certainly was, yeah, but you know, what [laugh] what I learned is that there's the status called an affiliated researcher. So, I didn't necessarily have to be a professor or someone on the tenure track in order to continue doing research.Corey: Was it hard for you?Kate: So, the book project, which is titled Illustration in Fin-de-Siècle Transatlantic Romance Fiction, and has a chapter devoted to H. Rider Haggard, I wrote it, while really not even being an instructor or sort of traditional academic. I had access to the library through this affiliated researcher status, which I maintained by keeping a relationship with the folks at Georgia Tech, and was able to do all my research while you know, having a job in industry. And I think what a lot of academics need to do is think about what it is about academia that they really value. Is it the teaching?Because in industry, we spend a lot of time teaching [laugh]. Sharing our knowledge is something that's extremely important. Is that the research? As an analyst, I get to do research all the time, which is really fun for me. And then, you know, is it really just kind of focusing on historical aspects? And that was also important to me.So, you know, this status allowed me to keep all the best parts of being an academic while kind of sloughing off the [laugh] parts that weren't so good, which is, um, say the fact that 80% of courses in the university are taught now by adjuncts or folks who are not on the tenure track line. Which is, you know, pretty shocking, you know. The academy is going through some… troubles right now, and hiring issues are—they need to be acknowledged, and I think folks who are considering getting a PhD need to look for other career paths beyond just through modeling it on their advisors, or, you know, in order to become, ostensibly, a professor themselves.Corey: I don't know if I've told the story before in public, but I briefly explored the possibility of getting a PhD myself, which is interesting given that I'd have to… there's some prerequisites I'd probably have to nail first, like, get a formal GED might be, like, step one, before proceeding on. And strangely enough for me, it was not the higher level, I guess, contribution to a body of knowledge in a particular direction. I mean, cloud economics being sort of an easy direction for me [laugh] to go in, given that I eat, sleep, live, and breathe it, but rather the academic rigor around so much of it. And the incentives feel very different, which to be clear, is a good thing. My entire career path has always been focused on not starving to death, and how do we turn this problem into money, whereas academia has always seemed to be focused on knowledge for the sake of knowledge without much, if any, thought toward the practical application slash monetization thereof? Is that a fair characterization from where you sit? I'm trying not to actively be insulting, but it's possible I may be unintentionally so.Kate: No, I think you're right on. And so yeah, like, the book that I published, I probably won't see any remuneration for that. There is very little—I'm actually [laugh] not even sure what the contract says, but I don't intend to make any money with this. Professors, even those who have reached the height of their career, unless they're, you know, on specific paths, don't make a lot of money, those in the humanities, especially. You don't do this to become wealthy.And the Visual Haggard archive, I don't—you know, everything is under a Creative Commons license. I don't make money from people, you know, finding images that they're looking for to reproduce, say, on a t-shirt or something. So yeah, I suspect you do it for the love. I always explained it as having a sort of existential anxiety of, like, trying to, you know, cheat death. I think it was Umberto Eco who said that in order to live forever, you have to have a child and a book.And at this point, I have two children and a book now, so I can just, you know, die and my, you know, [laugh] my legacy lives on. But I do feel like the reasons that folks go into upper higher education vary, and so I wouldn't want to speak for everyone. But for me, yeah, it is not a place to make money, it's a place to establish sort of more intangible benefits.Corey: This episode is sponsored in part by our friends at ChaosSearch. You could run Elasticsearch or Elastic Cloud—or OpenSearch as they're calling it now—or a self-hosted ELK stack. But why? ChaosSearch gives you the same API you've come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for app performance monitoring, cybersecurity. If you're using Elasticsearch, consider not running Elasticsearch. They're also available now in the AWS marketplace if you'd prefer not to go direct and have half of whatever you pay them count towards your EDB commitment. Discover what companies like Klarna, Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm, yet again.Corey: I guess one of the weird things from where I sit is looking at the broad sweep of industry and what I know of RedMonks perspective, you mentioned that as a postdoc, you taught technical communication. Then you went to go to frontend engineering, which in many respects is about effectively, technically—highly technical and communicating with the end-user. And now you are an analyst at RedMonk. And seeing what I have seen of your organization in the larger ecosystem, teaching technical communication is a terrific descriptor of what it is you folks actually do. So, from a certain point of view, I would argue that you're still pursuing the path that you are on in some respects. Is that even slightly close to the way that you view things, or am I just more or less ineffectively grasping at straws, as I am wont to do?Kate: No, I feel like there is a continuous thread. So, even before I got my PhD, I got a—one of my bachelor's degrees was in art. So, I used to paint murals; I was very interested in public art. And so, it you know, it feels to me that there is this thread that goes from an interest in the arts and how the public can access them to, you know, doing web development that's focused on the visual aspects, you know, how are these things responsive? What is it that actually makes the DOM communicate in this visual way? You know, how are cascading style sheets,allowing us to do these sorts of marvelous things?You know, I could talk about my favorite, you know, selectors and things. [laugh]. Because I will defend CSS. I actually don't hate it, although we use SASS if it matters. But you know, that I think there's a lot to be said for the way that the web looks today rather than, you know, 20 years ago.So there, it feels very natural to me to have moved from an interest in illustration to trying to, you know, work in a more frontend way, but then ultimately [laugh] move from that into doing, sort of, QA, which is, like, well, let's take a look at how we're communicating visually and see if we can improve that to, you know, look for things that maybe aren't coming across as well as they could. Which really forced me to work in the interactive team more with the UI/UX folks who are, you know, obviously telling the designers where to put the buttons and, you know, how to structure the, you know, the text blocks in relationship to the images and things like that. So, it feels natural to me, although it might not seem so on the outside. You know, in the process, I really I guess, acquired a love of that entire area.And I think what's great about working at RedMonk now is that I get to see how these technologies are evolving. So, you know, I actually just spun up a site on [unintelligible 00:16:27] not long ago. And, I mean, it is so cool. I mean, you know, coming from a background where we were working with, you know, jQuery, [laugh] things have really evolved. You know, it's exciting. And I think we're seeing the, [like, as 00:16:39] the full stack approach to this.Corey: I used to volunteer for the jQuery infrastructure team and help run jquery.net, once upon a time.Kate: Ohh.Corey: I assume that is probably why it is no longer in vogue. Like, oh, Corey was too close to it got his stink all over the thing. Let's find something better immediately, which honestly, not the worst approach in the world to take.Kate: I'm so impressed. I had no idea.Corey: It was mostly—because again, I was bad at frontend; always have been, but I know how to make computers run—kind of—and on the backend side of things and the infrastructure piece of it. It's like I tend to—at least at the time—break the world into more or less three sets: You had the ops types, think of database admins and the rest; you had the backend engineers, people who wrote code that made things talk to each other from an API perspective, and you had frontend folks who took all of the nonsense and had this innovative idea that, “Huh, maybe a green screen glowing text terminal isn't the pinnacle of user experience that we might possibly think about, and start turning it into something that a human being can use.”And whatever I hear folks from one of those constituencies start talking disparagingly about the others, it's… yeah, go walk a mile in their shoes and then tell me how you feel. A couple years ago, I took a two week break to, all right, it's time for me to learn JavaScript. And by the end of the two weeks period, I was more confused than I was when I began. And it's just a very different way of thinking than I have become accustomed to working with. So, from where I sit, people who work on that stuff successfully are effectively just this side of wizards.I think that there's—I feel the same way about database types. That's an area I never go into either because I'm terrible at that, and the stakes over their company-killing proportions in a way that I took down a web server usually doesn't.Kate: Yeah, I think that's often the motto, well, at least at my last company, which was like, “It's just a website. No one will die.” [laugh].Corey: Honestly, I find that the people who have really have the best attitude about that tend to be, strangely enough, military veterans because it's, “The site is down. How are you so calm?” It's, “Well, no one's shooting at me and no one's going to die? It's fine.” Like, “We're all going to go home to our families tonight. It'll work out.” It having perspective is important.Kate: Yeah. It is interesting how the impetus—I mean, going back to your question about, you know, making money at this field, you know, how that kind of factors in, I guess, frontend does tend to have a more relaxed attitude than say, yeah, if you drop a table or something. But at the same time, you know, compared to academia, it did feel a little bit more [laugh] like, “Okay, well, this—you know, we've got the project manager that is breathing down our neck. They got to send them something, you know, what's going on here?” So, yeah, it does become a little bit more, I don't know, these things ramped up a little bit, and the importance, you know, varies by, you know, whatever part of it you're working on.It's interesting, as an analyst, I don't hear the terms backend and frontend as much, and that was really how my team was divided, you know? It was really, kind of, opaque when you walked in. Started the job, I was like, “Okay, well, is this something that the frontend should be dealing with or the backend? You know, what's going on?” And then, you know, ultimately, I was like, “Oh, no, I know exactly what this is.”And then anyone who came on later, I was like, “No, no, no. We talk to the backend folks for this sort of problem.” So, I don't know if that's also something that's falling out of vogue, but that was, you know, the backend handled all the DevOps aspects as well, and so, you know, anything with our virtual boxes and, you know, trying to get things running and, you know, access to our… yeah, the servers, you know, all of that was kind of handled by backend. But yeah, I worked with some really fantastic frontend, folks. They were just—I feel like they we could bet had been better categorized as full stack. And many of them have CS degrees and they chose to go into frontend. So, you know, it's a—I have no patience for, you know—Corey: Oh God, you mean you chose this instead of it being something that happened to you in a horrible accident one of these days?Kate: [laugh]. Exactly.Corey: And that's not restricted to frontend; that's working with computers, in my experience.Kate: [laugh].Corey: Like, oh, God, it's hard to remember I chose this at one point. Now, it feels almost like I'm not suited for anything else. You have a clear ability to effectively communicate technical concepts. If not, you more or less wasted most of your academic career, let's be very clear. Then you decided that you're going to go and be an engineer for a while, and you did that.Why RedMonk? Why was that the next step because with that combination of skills, the world is very much your oyster. What made you look at RedMonk and say, “Yes, this is where I should work?” And let me be very clear. There are days I have strongly considered, like, if I weren't doing this, where would I be? And yeah, I would probably annoy RedMonk into actively blocking me on all social media or hiring me. There's no third option there. So, I agree wholeheartedly with the decision. What was it that made it for you?Kate: I mean, it was certainly not just one thing. One of the parts of academia that I really enjoyed was the ability to go to conferences and just travel and really get to meet people. And so, that was something that seemed to be a big part of it [unintelligible 00:21:27] so that's kind of the part that maybe doesn't get mentioned so much. And then especially in the Covid era, you know, we're not doing as much traveling, as you're well aware.Corey: We're spending all of our time having these conversations via screen.Kate: You know, I do enjoy that.Corey: Yeah. Like in the before times, probably one out of every eight episodes or so of this show was recorded in person.Kate: Wow.Corey: Now, it's, “I don't know. I don't really know if I want to go across town.” It's a—honestly, I've become a bit of a shut-in here. But you get it down to a science. But you lose something by doing it.Kate: That's true.Corey: There's a lack of high bandwidth communication.Kate: And many of my academic friends, when they would go to conferences, they would just kind of hide in their hotel room until they had to present. And I was the kind of person that was down in the bar hanging out. So, to me, it [laugh] felt very natural. But in terms of the intellectual parts, in all seriousness, I think the ability to pull apart arguments is something that I just truly enjoy. So, when I was teaching, which of course was how—was why they paid me to be an academic, you know, I loved when I could sit in a classroom and I would ask a question. You know, I kind of come up with these questions ahead of time.And the students would say something totally unexpected, and then I'd have another one, say something totally out of the blue as well. And I get to take them and say, “You're both right. Here's how we combine them, and here's how we're going to move forward.” Sort of, the ability to take an argument and sort of mold it into something constructive, I think can be very useful, both in, you know, meeting with clients who maybe are, you know, coming at things a little bit differently than then maybe we would recommend in order to, you know, help them to reach developers, the practitioners, but also, you know, moderating panels is something that a lot of my colleagues do. I mean, that's a big part of the job, too, is, you know, speaking and… well, not only doing sort of keynote talks, which my colleague Rachel is doing that at, I think, a [GlueCon 00:23:14] this year.And then—but also, you know, just in video format, you know, to having multiple presenters and, kind of, taking their ideas and making something out of that sort of forwards the argument. I think that's a lot of fun. I like to think I do an okay job at it. And I certainly have a lot of experience with it. And then just finally, you know, listening to argument [unintelligible 00:23:30] a big part of the job is going to briefings where clients explain what their product does, and we listen and try to give them feedback about how to reach the developer audience, and, you know, just trying to work on that communication aspect.And I think what I would like to push is more of the visual part of this. So, I think a lot of times, people don't always think through the icons that they include, or the illustrations, or the just the stock photos. And I find those so fascinating. [laugh]. I know, that's not always the most—the part that everyone wants to focus on, but to me, the visuals of these pitches are truly interesting. They really, kind of, maybe say things that they don't intend always, and that also can really make concrete ideas that are, especially with some of this really complex technology, it can really help potential buyers to understand what it accomplishes better.Corey: Some of the endless engagements I've been on that I enjoy the most have been around talking to vendors who are making things. And it starts off invariably as, “Yeah, we want to go ahead and tell the world about this thing that we've done.” And my perspective has always been just a subtle frame shift. It's like, “Yeah, let me save some time. No one cares. Absolutely no one cares. You're in love with the technical thing that you built, and the only people who are going to love it as much as you do are either wanting to work where you, or they're going to go build their own and they're not going to be your customer. So, don't talk about you. No one cares about you. Talk about the pain that you solve. Talk about the painful thing that you're target customer is struggling with that you make disappear.”And I didn't think that would be, A, as revelatory as it turned out to be, and B, a lesson that I had to learn myself. When I was starting o—when I was doing some product development here where I once again fell into the easy trap of assuming if I know something, everyone must know it, therefore, it's easy, whereas if I don't know something, it's very hard, and no one could possibly wrap their head around it. And we all come from different places, and meeting people wherever they are in their journey, it's a delicate lesson to learn. I never understood what analysts did until I started being an analyst myself, and I've got to level with you, I spent six months of doing those types of engagements feeling like a giant fraud. I'm just a loudmouth with an opinion, what is what does that mean?Well, in many ways, it means analyst. Because it's having an opinion is in so many ways, what customers are really after. Raw data, you can find that a thousand different ways, but finding someone who could talk on what something means, that's harder. And I think that we don't teach anything approaching that in most of our STEM curriculum.Kate: Yeah, I think that's really on point. Yeah, I mean, especially when some of these briefings are so mired in acronyms, and sort of assumed specialization. I know I spend a lot of time just thinking about what it is that confuses me about their pitch, more so than what, you know, is actually coming through. So, I think actually, one of the tools that we use—writing instructors; my past life—was thinking like someone with an eighth grade education. So, I actually think that your reference to having [laugh] you know, that's sort of chestnut, that can actually be useful because you say, “If I, you know, took my slide deck and showed it to a bunch of eighth graders, would they understand what it is that I'm saying?”You know, maybe you don't want them to get the technical details, but what problem does it solve? If they don't understand that, you're not doing a good enough job. And so that, to me, is [laugh] actually something that a lot of folks need to hear. That yeah, these vendors because they're just so deep in it, they're so in the weeds, that they can't maybe see how someone who's just looking for a database, or a platform, or whatever, they actually need this sort of simplified and yet broad enough explanation for what it is that they're actually trying to do what service they actually provide.Corey: From where I sit, one of the hardest things is just reaching people in the right way. And I'm putting out a one to two-thousand word blog post every week because I apparently hate myself. And that was a constant struggle for me when I started doing that a year or two ago. And what has worked for me that really get me moving down that is, instead of trying to teach everyone all the things, I pick an individual—and it varies from week to week—that I think about and I want to explain something to that person. And then I wind up directing what it is I'm about to tell—what it is I'm writing—to that person.Sometimes they're a complete layperson. Other times they are fairly advanced in a particular area of technology. And the responses to these things differ, but it's always—I always learn something from the feedback that I get. And if nothing else, is one of those ways to become a better writer. While I would start by writing. Just do it, don't whine—don't worry about getting it perfect; just go out there and power through things.At least, that's my approach. And I'm talking about the burden of writing a thousand words a week. You wrote an actual book. My belief is that, the more people I've talked to who've done that, no one actually wants to write a book; people want to have written a book, and that definitely resonates with me. I am tempted to just slap a bunch of these—Kate: Yeah.Corey: —blogs posts together and call it a book one of these days as an anthology. But it feels like it's cheating. If I ever decide to go down that path, I want to do it right.Kate: I guess, I come at it from the perspective of I don't know what I think until I write it down. So, it helps me to formulate ideas better. I also feel like my strength is in rereading things and trying to edit them down to really get to the kernel of what it is I think. And a lot of times how I begin a chapter or a blog post or whatever is not where it should begin, that maybe I'm somewhere in the middle, maybe this is a conclusion. There's something magical, in my view, that [laugh] happens when you write, that you are able to pause and take a little bit more time and maybe come up with a better word for what it is that you're trying to communicate.I also am—I benefit from readers. So, for instance, in my book, I have one chapter that really focuses on Harper's Weekly, which is an American newspaper. I'm not an Americanist; I don't have a deep knowledge of that, so what I did is I revise that chapter and send it to American periodicals and got feedback from their readers. Super useful. In terms of my blog at RedMonk, anytime I publish something, you can bet that at least one founder and probably at least one other analyst has read it through and giving me some extremely incisive feedback. It never is just from my mind. It's something that is collaboration.And I am grateful to anyone who takes the time to read my writing because, you know, all of us have so much time, of course. It really helps me to understand what it is that I'm trying to dig into. So, for instance, I've been writing a series for RedMonk on certifications, which makes a lot of sense; I've come from an academic background, here it is, you know, I'm seeing all these tech certifications. And so, it's interesting to me to see similarities and differences and what sort of issues that we're seeing come up with them. So, for instance, I just wrote about the vendor-specific versus vendor-neutral certifications. What are the advantages of getting a certification from the CN/CF versus from say, VMware and—Corey: Oh, I have opinions, on all of [those 00:30:44]—Kate: I—Corey: —and most of them are terrible.Kate: —I'm sure you do. [laugh]. It came naturally out of the job, you know, sitting through briefings and, kind of, seeing these things evolve, and the questions that I have from a long history of teaching, but. I think it also suggests the collaborative aspect of this, of coming to my colleagues—you know, I've been here before, for what, four months?—and saying, you know, “Is this normal? Like, what are we seeing here? Let me write a little bit about what I think is going on with certifications, and then you tell me, you know, what it is that you've seen with your years and years of expertise,” right?So, Stephen O'Grady's been doing this for longer than he really likes to admit, right? So, this is grateful to have such well-established colleagues that can help me on that journey. But, you know, to kind of spiral back to your original question, I think that writing to me is an exploration, it's something that helps me to get to something a little more, I guess, meaningful than just where I began. You know, just the questions that I have, I can kind of dig down and find some substance there. I would encourage you to take any one of your blog posts and think about maybe where they—or using the jumping off points for your eventual book, which I will be looking for on newsstands any day now.Corey: I am looking forward to seeing how you continue to evolve your coverage area, as well as reading more of your writings around these things. I am—they always say that the cobblers children have no shoes, and I am having an ongoing war with the RedMonk RSS feed because I've been subscribed to it three times now, and I'm still not seeing everything that comes through, such as your posts. Time for me to go and yell at some people over on your end about how these things work because it is such good content. And every time RedMonk puts something out, it doesn't matter who over there has written it, I wind up reading it with this sense of envy, in that I wish I had written something like this. It is always an experience, and your writing is absolutely no exception to that. You fit in well over there.Kate: It means a lot to me. Thank you. [laugh].Corey: No, thank you. I want to thank you for spending so much time talking to me about things that I feel like I'm still not quite smart enough to wrap my head around, but that's all right. If people want to learn more, where's the best place to find you?Kate: Certainly Twitter. So, my Twitter handle is just my name, @kateholterhoff. And I don't post as often as maybe I should, but I try to maintain an ongoing presence there.Corey: And we will of course, put a link to that in the [show notes 00:33:04].Kate: Thank you.Corey: Thank you so much for your time. I appreciate it. Kate Holterhoff, analyst at RedMonk. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice—or if you're on YouTube, smash that like and subscribe button—whereas if you've hated this podcast, please do the exact same thing—five-star review, smashed buttons—but then leave an angry, incoherent comment, and it's going to be extremely incoherent because you never learned to properly, technically communicate.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
Upstream: The Software Supply Chain Security Podcast presented by Anchore
In this episode, Kim Weins and Josh Bressers engage Stephen O'Grady, co-founder and principal analyst at RedMonk, on how improving the developer experience can pay dividends for security up and down the software supply chain.
About BrookeBrooke is the Head of Enablement - AI/ML and Data at Blackbook.ai, an Australian based consulting firm and AWS Partner. Brooke has degrees in Mathematics and Data Engineering and they specialise in developing technically robust solutions that help “non-data people” harness the power of AI for their industry, and communicate this effectively.Outside of their 'day job', Brooke speaks at Data, AI, Software Engineering, UX and Business conferences and events to Australian and international audiences, and has guest lectured at the University of Queensland Business School and Griffith University. Brooke is proudly a volunteer member of the Queensland National Science Week Committee, and is always on the lookout for new ways to promote STEM pathways to young people, especially young women and members of the LGBTIQA+ community from regional Australia.Links: Blackbook: https://blackbook.ai/ Twitter: https://twitter.com/brooke_jamieson TikTok: https://www.tiktok.com/@brookebytes LinkedIn: https://www.linkedin.com/in/brookejamieson/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: The company 0x4447 builds products to increase standardization and security in AWS organizations. They do this with automated pipelines that use well-structured projects to create secure, easy-to-maintain and fail-tolerant solutions, one of which is their VPN product built on top of the popular OpenVPN project which has no license restrictions; you are only limited by the network card in the instance.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They've also gone deep in-depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That's S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. As my 30s draw to a close, I am basically beating myself up emotionally by making myself feel tremendously, tremendously old. And there's no better way to do that than to go on TikTok where it pops up with, “Hey if you were born before 2004”—and then I just closed the video because it's ridiculous. It's more or less of a means of self-flagellation.But there are good parts to it. One of those good parts is I get to talk to people who I don't generally encounter in other areas of the giant cloud ecosystem, and my guest today is a shining example of someone who has been very prolific on TikTok but for some reason or other, hadn't really come across my radar previously. Brooke Jamieson is the Head of Enablement of AI and machine learning at Blackbook. Brooke, thank you for joining me today.Brooke: Thanks so much for having me. Welcome to 6 a.m. in Brisbane. [laugh].Corey: It was right before the pandemic that I did my first trip to Australia, discovered that was a real place. Like, “Oh, yeah. You're going to go to give a talk in Perth. What, are you taking a connection through Narnia?” No, no, it turns out it's a real place, unlike New Zealand.Brooke: Oh, yeah. New Zealand's fake.Corey: [laugh].Brooke: I booked a conference in Portugal soon, and it's going to take me 31 hours to get there from here. So. [laugh].Corey: I remember the days of international travel. Hopefully for me, they'll come back again, sooner or later.Brooke: Fingers crossed.Corey: What really struck my notice about a lot of your content is the way that you fold multiple things together. First and foremost, you talk an awful lot about machine learning, data engineering, et cetera, and you are the second person that I've encountered that really makes me think that there is something to all of this. The first being Emily Freeman, which I've discussed on the show previously, and on Twitter, and shouting from the rooftops because she works at AWS and is able to tell the story, which basically, I think makes her a heretic compared to most folks over in that org. But there's something about making incredibly complex things easily accessible, which is hard enough in its own right, but you also managed to do it basically via short-form video on TikTok. How did you discover all this?Brooke: Yeah, I have a very strange resume. [laugh]. It is sort of a layered Venn diagram is the way I normally talk about it if I'm doing a conference talk or something. So, I studied pure maths at university the first time, and then I went back and studied data engineering after. But then I also worked in fashion as a model internationally, and then I've also worked in things like user experience, doing lots of behavioral science, and everything even design-related around that.And then I've also done lots more work into cloud and AI and everything that happens. So overall, it's just being about educating people on this. Most of my role now is educating executives and showing them how they were lied to at various conferences so that they can actually make an informed decision. Because if I go to talk to a board, I know when I leave, they're going to have a conversation about what we talked about without me in the room, and I think executives keep making terrible decisions because they can't have that conversation as a group. They don't know what to do when the tour guide isn't there anymore because they don't have a shared vocabulary or a framework to talk about what they might like to do, or what they might like to prioritize to do first, things like that.So, so much of what I do is just really helping people to understand, conceptually from a high level what they're actually trying to do, so that then they can deliver on that rather than thinking, oh, I just really saw this cool model of a specific AI thing at a conference, and it was a cool animated slide. And I would like to purchase exactly one of those for my company, thank you.Corey: It's odd because you don't have a quote-unquote, “Traditional”—if there is such a thing—DevRel role: You're not an advocate, you're not an evangelist. And none of your content and talks that I have seen have been actively selling any product, but they very much been selling ideas and concepts. And it really strikes me that you have threaded the needle beautifully as far as understanding the assignment. You're trying to cause a shift in the audience, get them to see things in a way that they don't already without trying to push a particular product or a particular solution. How much of that was happy accident and how much of that was something you set out to do intentionally?Brooke: First, thanks so much. Second of all, I think this comes from studying maths. So, the number one skill you get from doing a pure maths degree is you have a toolbox with you, and then there's a number of things in that toolbox. There's different ways you can solve problems, and usually, there's a few different ways you can solve a given problem, but you just open up your toolbox that grows over time, and you can see what you can use in there to solve a problem. So, that's really how I've continued to exist, even working in user experience roles as well, just like what elements do we have to even work with here?And I brought that with me into the cloud as well because I think the really big thing with actually selling tech products is being confident enough to know that there are a number of things you can actually use instead of your product, but if you're confident enough in the product you have, it will be the obvious solution anyway, so instead, I just get people thinking about what they actually need it for, how they could use it solving a problem and give them ideas on how to apply it. And you would know this: In cloud, there's always ten million different ways to do something. [laugh]. And it's just, instead of getting them to think—because then you just get stuck in a thought vortex about, “This one or this one?” Or, “What am I doing,” but instead latch on to an idea of what you're trying to achieve, and then work out the most optimal way to do that for your underlying infrastructure as well. And even the training of staff that you have, is really important.Corey: There's a definite idea around selling—like, I think it's called ‘solution selling.' I don't know; I don't have a background in this stuff. I've basically stumbled into it. But periodically, I'll have folks come on this show, and I'll chat with them, “So, what is the outcome we're looking to have in the audience here?” Because again, telling a story with no real target in mind doesn't always go super well. And, “Oh, I want people to sign up for my product.” “Okay, how do you envision them doing that?”And their story is to sit there and pitch the whole time, and it's, yeah, that's going to be a really bad show, and I don't want to put that out. Instead, if you're active in a particular space, my approach has always been to talk about the painful problem that you solve and allude to what you do and a bit of how you do it. If you make the audience marinate in the painful problem, the folks who are experiencing that are going to sit up and self-select of, “Ooh, that sounds a lot like the problems we have. If they're talking about this, they might have some ideas and solutions.” It's a glimpse and a hook into reaching out to find out more.And to be clear, that's not the purpose of this show, but if someone wants to pitch a particular product or service, that's the way to do it because the other stuff just doesn't work. Giving away free t-shirts, for example, okay, you'll get a bunch of people clicking links and whatnot, but you're also effectively talking to people who are super willing to spend time filling out forms and talking to people to get a free t-shirt. I don't know that for many products, that's the best way to get qualified leads in.Brooke: Yeah, it's tricky. And I think it's just because everyone's doing what everyone told them to do. I love reading really terrible sales books. I started when I was younger, just because I could see people trying to use these tactics on me; and I just wanted to know everything there was to know about what it's like to be a used car salesman in the middle of [laugh] America. And so I've read all of these things, and lots of the strategies in them, they only work if you're in a very specific area that they're actually working in, and no one's getting to the problem of how do you actually like to be sold to? How can you improve the experience?And overall, for consulting, usually, it's someone—the best end game is someone has seen you around doing other things, and then they come back and they're like, “I've got a really weird problem. I didn't even know if this is what you can do. Can you help me with this?” And that is—the best client to have, they're the best—they're so open to ideas, they trust you because they've seen you do good work over time. And you would have seen this so many times, it's about someone just come to you with a really strange problem, and it may or may not even be what you've actually helped them with.Corey: Help me understand a bit what you do as a Head of Enablement? Because I've heard the term a few different ways, always at different companies. As far as day job goes, where do you start? Where do you stop?Brooke: Yeah, it's a very fake-sounding job title.Corey: [unintelligible 00:08:53]—“Oh, what are you?” “Oh, I'm an enabler.” Like, effectively standing behind someone who's debating relapsing into something, like, “Do it. Do it. Do it.” Now, I don't imagine that's what you do. But then again, AI and ML is a weird space. Maybe it is.Brooke: Just when my friends are online shopping, and they're not sure if they should buy something. I'm the one messaging them saying, “Yes, get it.” That's me. So no, what I do is I—there's really technical people in our teams, we've got about 150 consultants across Australia, and then there's very non-technical business executives who have a problem. And if you don't have a good conduit between those two groups, the business won't get what they need, and the technical people won't have the actual brief they need to solve the problem.Because so many times people will come to us with what they think is a problem, but it's actually a symptom, not the root cause, so you just need a really good understanding of overall how businesses work, how business processes work, as well, and then also just really good user experience, information architecture knowledge to go through that. But then all of that would only work if I also had the technical underpinnings so I can then make sure we have everything we need and then communicate that to the development team to make sure that everyone's getting what they need from it. Lots of places, my job doesn't exist in a lot of companies, and that's because they just try to mash [laugh] those two groups together with varying levels of success.Corey: Or it's sales enablement of, “Here's the pitch deck you use. I'm going to build slides all day,” et cetera. “Here's what the engineers are going to babble about. When they use this phrase, go ahead and repeat this talking point and they'll shut up and go away,” is often how it manifests. And I don't get that sense from you at all.I'm going to call you out slightly on this one. The way you just describe it like, “Well, there are some very technical people, and there are some non-technical people.” And you didn't actually put yourself into either one of those categories, but let's call out a bit of background on you. You have a degree in mathematics, but that wasn't enough, so you decided to go a little more technical than that; you also have a degree in data engineering. If you're listening to this, please don't take this the wrong way—Brooke: Definitely take it the wrong way. [laugh].Corey: —but you do not present as someone who is first and foremost like, “Code speaks. Code is everything,” the stereotypical technical person who gets lost in their absolute love of the technology to the exclusion of all else. You speak in a way that makes this stuff accessible. Never once in watching any of your content, have I come away feeling dumb as a result, and that's an incredibly rare thing. But make no mistake, you are profoundly technical on these things.Brooke: Yeah, making people not feel worried is my number one marketable skill when talking to executives because executives make bad decisions when they don't know how to have that conversation. But all of that is because they've been rising up in their organization for 20 to 30 years, and they didn't ask questions early on when tech was new, and then it's gotten to a point where they feel like they can't ask questions [laugh] anymore because they're the one in charge, and they're too nervous to admit they don't understand something. So, much of what I do that is successful when talking to executives is just really making sure that I'm never out to try and look like the smart one. So, I'm not ever just flexing technical knowledge to make people think that I am the God Almighty of all things tech.I don't care about that, so it's mostly about how can I make people really comfortable with something that they've been too scared to ask about probably for quite some time? So that then they can make an informed choice on that front and so they can actually be empowered by that knowledge that they now have. They probably were too scared to ask it the whole time. But it's just a way of getting through to them. And then you get so much trust from that as well, just because, as well, I'm always very confident to tell people if they've been given the wrong information by other parties, I will absolutely tell them immediately, or if they just don't know how to give success metrics for project, so they end up just forgetting that false negatives or false positives can exist. [laugh].So, educating them, even on accuracy and recall measures and things like that, as well and doing it in a way where they don't ever feel threatened is the number one key to success that no one ever tells you about as a thing because no one wants to even admit that people could possibly be threatened by this.Corey: A lot of the content that you wind up building is aimed around career advice, particularly for folks early on in their careers. And the reason I bring that up is that you are alluding to something that I see when I interview folks all the time—I went through it myself—where there was a time you're going through a technical interview, and you get the flop sweat where I don't know the answer to this question. And there are a few things you can do: You can give up and shut down, which okay, that is in many cases are natural inclination, but not particularly helpful in those environments; you can bluff your way through the answer, which I generally don't advise because when an interviewer is asking you a technical question, it's a reasonable guess that they know the right answer; but the mark of seniority that it took me a distressingly long time to learn this is I just sometimes laugh, I say, “I have absolutely no idea, but if I had to guess…” and then I'll speculate wildly. And that, in my experience, is the mark of the kind of person you generally want to have on your team. And there are elements of what you just said, threaded throughout that entire approach of not making people feel less than.On the other side of that interview table, when I'm sitting there as a candidate. I hated those interviews where someone sits there and tries to prove they're the smartest person in the room. Yeah, I too, am the smartest person in the room when I wrote the interview questions. But for me, it's a given Tuesday; for the person I'm interviewing, it's determining the next stage of their career. There's a power imbalance there.Brooke: Yeah. And this has always happened to me in job interviews as well. I have a very polarizing resume just because it's not traditional. I didn't do software engineering at university and then work as a software engineer. I just haven't gone through that linear pathway, so there's lots of people just trying to either figure me out or get to a gotcha moment where they can really just work out what's actually happening.I have no interest in it. I'm happy to say that I don't know something. And being able to openly say that you don't know something is so helpful, as you're saying. It's the number one skill I wish people would learn because it's fine to not [laugh] understand things.Corey: A couple of times, I was the first DevOps hire in startup that was basically being interviewed by a bunch of engineers. And I went through a lot of those interviews and took the job only a couple of times, and one of the key differentiators for me was when they sat down and looked sort of sheepish and asked me a question of the form, “Look, I know how to interview a software engineer, but I sort of get the sense that you're not going to do that super well.” Yeah, surprise; I'm not a software engineer. “What is the best way to interview you to really expose where you start and where you stop?” Which I think is such a great question, if you don't know.Now, in my world, the way that—now that I'm on the other side of the table, I bring in experts to help me evaluate people, otherwise I run the very real risk of hiring the person that sounds the most confident, and that doesn't generally end well in technical spaces. And really figure out what it is that makes people shine. Everyone talks about how to pass the technical interview, but there's very little discussion on the other side of it, which is what kind of training do most of us—are most of us given to effectively conduct a technical interview?Brooke: Yeah, and not even just interview skills, but leadership skills. Number one thing I always talk to you when I'm talking to university students is I let them know that probably the manager they will end up having, if they work in tech, probably has no leadership training or management training of any sort. So, [laugh] if you are just assuming that they will be, like, really just a straight, always making the best management decision or always doing something the most perfect way, they probably have no idea what they're doing as well. And that's really important for people to go into jobs and interviews knowing, is that it's fine if the other person doesn't know as well. Do they want you to win? I think that's the number one thing I always am left with after interviews.And even when I was interviewing—I worked as a marketing manager for a while, so even when I was interviewing for marketing jobs, you could tell whether the person on the other side of the table wanted you to do well or not. And especially when you're looking for an early career job, regardless of any other factor, if someone wants you to do well, that is a good job for you to have. It will just mean so much more to your momentum throughout your career.Corey: I'm a big believer in even if you decide not to continue with a particular candidate, my objective has always been that I want them to think well of the company, I want them to consider reapplying down the road when their skill set changes or what we're looking for changes. And I want them to walk away from the experience with a, “That was a very fair and honest experience. I might recommend applying there to other people I know.” And we've had some people come through that way, so we're definitely succeeding. Whereas I went through the Google SRE interview twice—the second time, I think, was in 2015—and I swore midway through the process that even if they offered me the job, I wouldn't accept it because they didn't want to work with a place where they were going to treat people like that.Full disclosure, I did not get the offer because I'm bad at solving, you know, coding challenges in a Google Doc. Who knew. But it was one of those, I will not put myself through that again. So yeah, it turns out now I've made myself completely unemployable by anyone, so problem solved. “Oh, yeah, I'm never going to put myself through one of those job interviews,” says man who made himself completely un-interviewable, any job ever, ever again. I'll have to change my name and enter witness protection if I want to [laugh] enter the industry after the nonsense I'm pulling.Brooke: Just wear a mustache. They'll never know.Corey: Oh, yeah, you joke but I—some of me wonders on that one. So, I am curious as to your adventures with TikTok. I know I started the show talking about that, but it's still a weird format for me. I thought I got weird comments on Twitter. Oh, no, no, no, not compared to some of the people responding to things on the TikToks.And it's a different format, it's a different audience, it feels like, but there's still a strong appetite for career discussions and for technical discussions as well. How did you stumble on the platform? And how did you figure out what you would be talking about there?Brooke: Yeah, I put off making a TikTok for so long. So, I worked as a model internationally before my current job—I did it during and after uni—and so I have a very fashion Instagram that's very polished… like, I put thought into the outfits that I'm wearing in photos, which means I just haven't posted a lot lately because I just don't have the energy. So, the idea of going on TikTok to do something that is very quick is horrible to me [laugh] as a thought. Also, I hid my fashion past, I was closeted for a long time in tech, just because it was actively negatively impacting career prospects. But one of the best gifts about moving to a leadership team in a management space is that people don't care about that as much anymore, which is really good.So, just it was a big move for me in terms of bringing my closeted to past back into what I'm actually doing in tech, just to get more people aware of the opportunities that are out there. Because there's so many people during Covid that wanted to work from home and they wanted to transition to a job that would allow them to work remotely with benefits and security and everything that goes along with that, and tech is a really good industry to get that in.Corey: Oh, there are millions of jobs now that didn't exist two years ago that empower full remote, either within a given country or globally. Just, do you have an internet connection wherever you happen to be? I mean, we have people here who are excited to go and do all kinds of traveling, and we have people who have—this has been challenging for them—but, on the paperwork on our side, just fill up the forms, but we've had to effectively open tax accounts with different states as they relocate during the course of the pandemic. And power to them; that's what administrative teams are for. But it's really nice to be able to empower stuff like that because for the longest time—I live in San Francisco, and it felt like the narrative was, “We are a disruptive industry that is changing the face of the world. And we are applying that disruption by taking a job that can be done from literally anywhere and creating a land crunch in eight square miles in an earthquake zone.”It really didn't seem like it was the most forward-thinking type of event. And I'm hoping—in fact, we're seeing evidence of it—that this is going to be one of the lasting changes of the pandemic. People don't want to go back into the crappy offices.Brooke: Yeah. And especially in Australia, as well. So, when you're talking about San Francisco being crunched into eight miles, Australia is like that, but the whole country. So, it's a very large space, but there's only a few capital cities dotted around that I think more than 90-something percent of people live in those big centers.Corey: Yeah. Yeah, I made that mistake by taking my week down there and visit—and giving talks in Sydney, Melbourne, and Perth. And it was, well, why not? Like, I'm flying all the way over there. How far apart could it be?It's, “What do you mean, there's that many time zones? And the flight is how many hours to go from one side to the other?” Yeah, on professional advice for people who are considering doing that: Don't.Brooke: Yeah, it's not for the faint-hearted. But it also means that there's so many people that don't live in capital cities that could now work remotely for tech companies. Or I know friends that they originally lived in a capital city, and then have gone to move into regional centers. And as someone that grew up in a regional center, that's so important to be able to spread the tech ecosystem out further. It's 1000 kilometers from where I live now, which I don't know what that is in miles in freedom units, but probably it's about a ten-hour drive if you're driving there; if you're driving without stopping.So, it's a really long way away. And that's just—it's not, like, something you can just drive a few times over for a meetup. There's just nothing around for quite a long time. So, being able to disperse technical knowledge throughout the country is something that's really important to me, especially just because it's opening up futures for more diverse groups, even the people that are using tech in the vast majority of geographically distributed Australia are completely ignored from making that tech. And that's something that's really a growing issue that is getting fixed as there are more opportunities to move remote jobs there. But people don't even know that these jobs exist, so it's just about getting out into the regions to show people that it's possible.Corey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats V-U-L-T-R.com slash screaming.Corey: You were mentioning that you are about to embark on a 31-hour travel nightmare nonsense thing to go to Portugal to give a talk. What is the talk you're giving, and what's the venue?Brooke: It's for NDC Porto. And so, I've done NDC in Sydney, virtually, twice—Corey: NDC is… I'm sorry?Brooke: It's a really big conference. I think it started as… Norwegian something? Norwegian Developers Conference, someone will roast me in the comments of this.Corey: Well, not on this show. Generally, we get a pretty awesome audience base compared to, you know, the TikTok. So, I'm sure we'll excerpt parts of this for the TikToks, and then oh, then all hell is going to break loose.Brooke: [laugh]. That we'll find them. Yeah, it's a big conference series. So, they have them in Oslo, Copenhagen, Sydney, London, Melbourne, and Porto as well. So, it's quite a big—I think it's very eurocentric. I don't know if it would have be in any of the US audiences yet. But it's a really wholesome group.Last time I did the conference in Sydney, the segment before me was someone showing their pet llamas on camera. So… love that. [laugh]. But my talk is just about enterprise applications of AI and machine learning. So, it's mostly the same sessions that I give to executives; I just give it to software engineers, and then tell them about how I talk to executives while I'm doing it to show why it works.Corey: You also give periodic talks at universities as well. You have been very prolific on the speaking circuit. What's the common thread that winds up tying all of these disparate audiences together?Brooke: People ask me and I say yes. Um—[laugh].Corey: Hey, there we go.Brooke: Yeah. No, it's mostly about I just want to make this an easier pathway for other people. If you can see this art here—it's backwards, probably, but it says, “Be who you needed when you were younger.” I made this, and it's just how I go through my tech life. When I talk to high school students and university students, no one's ever honest with them about what it's actually like to have a job because everyone is just telling them how fantastic it is and how everyone will think it's so fantastic that they're a graduate of that institution, and they will get their dream job, and they'll ride home on a unicorn and everything will be perfect.And no adults are ever honest to people because everyone wants something from them. So, it is an absolute immense position of privilege to be able to go in and say, “Here is unfortunate realities of what you're about to step into.” Because my parents, neither of them worked in office, my mom teaches children with disabilities—so she's retired now—and my dad is a telephone technician, so like, I didn't know anyone working in office growing up, it wasn't part of what I did. So, I can't tell people that this is what networking actually is. That will be someone who you are in the room with right now who is extremely wealthy, and their parents own something, and they will sail through life. You need to work much harder than them. [laugh].And just being able to have these actual conversations with students—because it's so valuable—and it's guidance that I wish I had earlier on and that you can actually, if you're aware of what's happening in these systems, you can hedge against it. But it's just, I think it's doing students a disservice to not be honest to them, so I take a lot of pride in doing that. [laugh].Corey: I like doing that, but I'm also worried that I am going to send the wrong message if I do. Because let's be honest, I can get away with an awful lot of stuff based upon my perceived position in the industry, the fact that I am clearly self-employed—when you own the company, it turns out you can get away with a lot—and also I'm 15 to 20 years into my career, whereas if I pulled a lot of this nonsense fresh out of school in my first job, I would have been fired. No ‘would have' about it; I was fired and didn't even pull half of the jokes that I pull now. So, when I give interview advice on TikTok, like here's how you pick a fight with the interviewer. Yeah, if someone actually does that, it's not going to go well, so I live in fear of effectively giving the kind of advice that is actively harmful. If I'm going to do that, I at least try to put a disclaimer into it. But we'll see.Brooke: Yeah. And even just showing people that it is possible for an interviewer to not want you to do well. So, many people are not aware of that because the only idea they have of interviews is that… been something they've been told at whatever school or boot camp they went through that someone really wants them to succeed and will help them to develop their journey. That's not… it's not normal, so being able to actually decipher what is and isn't happening there is a really good skill. And people just aren't aware that things like that are possible, or even I don't know, as a… [unintelligible 00:27:33] person in STEM, I have a lot of sage advice to give to people about what it is and isn't like in reality.And that's where my history of very strange jobs comes into play as well. So, I worked at a car parts store for four years growing up, selling people different types of filters and fuel filters and sound systems for their car.Corey: And blinker fluid, depending on how sketchy the numbers look that month. Of course, of course.Brooke: Yeah. But people would come into the store and just ask for a man straightaway, or call up, and then I was the only one that had any physics education in the store, so some days if [my brother 00:28:08] wasn't working, so they would call up and ask for what type of resistance they needed for their car stereo, and I would tell them, but they would [unintelligible 00:28:17] put a man on. And then eventually they would be like, “I don't know. I have to ask Brooke.” And put me back on the phone, and I would just pretend to have never heard the start of it.But it's just, if you don't have a diverse background of jobs you've had, or different service jobs, it gives you more structure about how to actually talk about what it is like to work in tech because some bits are much worse than they appear, and some things are actually a lot better than they appear as well. It's just depending on who's talking about it in the media at a given day.Corey: And I've said it before—it's always worth repeating—this is what privilege looks like because it's easy for me to sit here and say, “Look, the stuff that I built, the company I've put together, the reputation for myself that I wound up establishing, well, I had to do it all myself. None of it was handed to me.” And that is true. However, I didn't have to fight against bullshit like that. I didn't have a headwind of people telling me that I was somehow unqualified or didn't belong in the place that I was in.When I made a pronouncement, even when it was wrong, it was presumed accurate until proven otherwise. So, there's a lot of stuff around this that just contributes to a terrible toxic environment. That is what privilege is, and you can't set that aside, you can't turn that away. And we all have privilege in different ways, but it's often considered to be controversial. I don't see it that way at all. It's one of those, “You were born on third base; you didn't hit a triple.”Brooke: And it's just about what you do with it, as well. There are some people who are immensely privileged and then they just do nothing to help anyone else. They don't let the ladder down for anyone else after them, so—Corey: “Send the elevator back down,” is what Stephen O'Grady over at RedMonk said, and is a phrase that's stuck with me for years now. And it's the perfect expression of it. It's as opposed to folks who wind up pulling up the rope behind them, “Well, screw you. I got mine.” No thanks.Brooke: Yeah.Corey: That's not how I want to be remembered.Brooke: And that's why it's so important to talk to people about this early in their career as well because these people will become a manager probably. So, then say, “Hey, when you are inevitably a manager, [laugh] you are in a position of power now. Here are things you can actively do that will be who you needed when you were younger.” That's what will actually help people, too. So, being able to really specifically say, once you are in an organization, you have the opportunity to make change, especially in graduate roles in organizations, I noticed they get so much bandwidth to actively make decisions because higher-ups are just so excited that there's someone young working there.So, being able to go through and look at what they are actually doing. And people trust you, then they trust your opinion, and they'll trust your opinion. Especially on issues like sustainability, everyone's just, “Oh, who's a child we can ask?” So, being able to then give them an answer that's helpful. Or say even, “I didn't know about this. Maybe you should ask someone that this affects.”Being able to then hand the microphone to someone else is a skill that is never actively taught to anyone. So, I think that's what's really—it's a slow part of diversity and inclusion changing over time, but it's a really important part of actively modeling that behavior of what it looks like to do a decent job.Corey: Brooke, I really want to thank you for taking the time to speak with me today. If people want to learn more, where's the best place to find you?Brooke: I'm on Twitter as @brooke_jamieson; I'm on TikTok as BrookeBytes, and I'm on LinkedIn is probably the best place to—I check that inbox the most. And my name is just Brooke Jamieson, which will be in the show notes.Corey: And we will, of course, put links to all of that in the [show notes 00:31:38]. Thanks again for your time. I really appreciate it.Brooke: Thanks so much for having me.Corey: Brooke Jamieson, Head of Enablement for AI, ML, and data at Blackbook. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a long, rambling, angry comment that says this is not the content that you expected, you were not happy with it at all, and if I really wanted to have these conversations, I should have instead first demonstrated both of our technical suitability by solving algorithm problems on a whiteboard.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
About KellyKellyAnn Fitzpatrick is a Senior Industry Analyst at RedMonk, the developer-focused industry analyst firm. Having previously worked as a QA analyst, test & release manager, and tech writer, she has experience with containers, CI/CD, testing frameworks, documentation, and training. She has also taught technical communication to computer science majors at the Georgia Institute of Technology as a Brittain Postdoctoral Fellow.Holding a Ph.D. in English from the University at Albany and a B.A. in English and Medieval Studies from the University of Notre Dame, KellyAnn's side projects include teaching, speaking, and writing about medievalism (the ways that post-medieval societies reimagine or appropriate the Middle Ages), and running to/from donut shops.Links: RedMonk: https://redmonk.com/ Twitter: https://twitter.com/drkellyannfitz TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Today's episode is brought to you in part by our friends at MinIO the high-performance Kubernetes native object store that's built for the multi-cloud, creating a consistent data storage layer for your public cloud instances, your private cloud instances, and even your edge instances, depending upon what the heck you're defining those as, which depends probably on where you work. It's getting that unified is one of the greatest challenges facing developers and architects today. It requires S3 compatibility, enterprise-grade security and resiliency, the speed to run any workload, and the footprint to run anywhere, and that's exactly what MinIO offers. With superb read speeds in excess of 360 gigs and 100 megabyte binary that doesn't eat all the data you've gotten on the system, it's exactly what you've been looking for. Check it out today at min.io/download, and see for yourself. That's min.io/download, and be sure to tell them that I sent you.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance query accelerator for the Oracle MySQL Database Service, although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLAP and OLTP—don't ask me to pronounce those acronyms again—workloads directly from your MySQL database and eliminate the time-consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. It's always a good day when I get to sit down and have a chat with someone who works over at our friends at RedMonk. Today is no exception because after trying for, well, an embarrassingly long time, my whining and pleading has finally borne fruit, and I'm joined by Kelly Fitzpatrick, who's a senior industry analyst at RedMonk. Kelly, thank you for, I guess, finally giving in to my always polite, but remarkably persistent requests to show up on the show.Kelly: Great, thanks for having me. It's great to finally be on the show.Corey: So, let's start at the very beginning because I am always shockingly offended whenever it happens, but some people don't actually know what RedMonk is. What is it you'd say it is that you folks do?Kelly: Oh, I love this question. Because it's like, “What do you do,” versus, “What are you?” And that's a very big difference. And I'm going to start with maybe what we are. So, we are a developer-focused industry analyst firm. You put all those things, kind of, together.And in terms of what we do, it means that we follow tech trends. And that's something that many industry analysts do, but our perspective is really interested in developers specifically and then practitioners more broadly. So, it's not just, “Okay, these are things that are happening in tech that you care about if you're a CIO,” but what tech things affect developers in terms of how they're building software and why they want to build software and where they're building software?Corey: So, backing it up slightly because it turns out that I don't know the answer to this either. What exactly is an industry analyst firm? And the reason I bring this up is I've been invited to industry analyst events, and that is entirely your colleague, James Governor's, fault because he took me out for lunch at I think it was Google Next a few years ago and said, “Oh, you're definitely an analyst.” “Okay, cool. Well, I don't think I am. Why should I be an analyst?”“Oh, because companies have analyst budgets.” “Oh, you said, analyst”—protip: Never get in the way of people trying to pay you to do things. But I still feel like I don't know what an analyst is, in this sense. Which means I'm about to get a whole bunch of refund requests when this thing airs.Kelly: I should hope not. But industry analysts, one of the jokes that we have around RedMonk is how do we explain to our families what an industry analyst is? And I think even Steve and James, who are RedMonk's founders, they've been doing this for quite a long time, like, much longer than they ever want to admit that they do, and they still are like, “Okay, how do I explain this to my parents?” Or you know, anyone else who's asking, and partly, it's almost like a very—a term that you'll see in the tech industry, but outside of it doesn't really have that much, kind of, currency in the same way that you can tell someone that you're like, maybe a business analyst or something like that, or any of those, almost like spy-like versions of analyst. I think was it The Hunt for Red October, the actual hero of that is an analyst, but not the type of analyst that I am in any way, shape or form.But you know, industry analyst firms, specifically, it's like we keep up on what tech is out there. People engage with us because they want to know what to buy for the things that they're doing and the things that they're building, or how to better create and sell the stuff that they are building to people who build software. So, in our case, it's like, all right, what type of tools are developers using? And where does this particular tool that our company is building fit into that? And how do you talk about that with developers in a way that makes sense to them?Corey: On some level, what I imagine your approach to this stuff is aligns somewhat with my own. Before you became an industry analyst, which I'm still not entirely sure I know what that is—I'm sorry, not your fault; just so many expressions of it out there—before you wound up down that path, you were a QA manager; you wound up effectively finding interesting bugs in software, documentation, et cetera. And, on some level, that's, I think, what has made me even somewhat useful in the space is I'll go ahead and try and build something out of something that a vendor has released, and huh, the documentation says it should work this way, but I try it and it breaks and it fails. And the response is always invariably the same, which is, “That's interesting,” which is engineering-speak for, “What the hell is that?” I have this knack for stumbling over weird issues, and I feel like that aligns with what makes for a successful QA person. Is that directionally correct, or am I dramatically misunderstanding things and I'm just accident-prone?Kelly: [laugh]. No, I think that makes a lot of sense. And especially coming from QA where it's like, not just making sure that something works, but making sure that something doesn't break if you try to break it in different ways, the things that are not necessarily the expected, you know, behaviors, that type of mindset, I think, for me translated very easily to, kind of, being an analyst. Because it's about asking questions; it's about not just taking the word of your developers that this software works, but going and seeing if it actually does and kind of getting your hands dirty, and in some cases, trying to figure out where certain problems or who broke the build, or why did the build break is always kind of super fun mystery that I love doing—not really, but, like, everyone kind of has to do it—and I think that translates to the analyst world where it's like, what pieces of these systems, or tech stacks, or just the way information is being conveyed about them is working or is not, and in what ways can people kind of maybe see things a different way that the people who are building or writing about these things did not anticipate?Corey: From my position, and this is one of the reasons I sort of started down this whole path is if I'm trying to build something with a product or a platform—or basically anything, it doesn't really matter what—and the user experience is bad, or there are bugs that get in my way, my default response—even now—is not, “Oh, this thing's a piece of crap that's nowhere near ready for primetime use,” but instead, it's, “Oh, I'm not smart enough to figure out how to use it.” It becomes a reflection on the user, and they feel bad as a result. And I don't like that for anyone, for any product because it doesn't serve the product well, it certainly doesn't serve the human being trying to use it and failing well, and from a pure business perspective, it certainly doesn't serve the ability to solve a business problem in any meaningful respect. So, that has been one of the reasons that I've been tilting at that particular windmill for as long as I have.Kelly: I think that makes sense because you can have the theoretically best, most innovative, going to change everyone's lives for the better, product in the world, but if nobody can use it, it's not going to change the world.Corey: As you take a look at your time at RedMonk, which has been, I believe, four years, give or take?Kelly: We're going to say three to four.Corey: Three to four? Because you've been promoted twice in your time there, let's be very clear, and this is clearly a—Kelly: That's a very, very astute observation on your part.Corey: It is a meteoric rise. And what makes that also fascinating from my perspective, is that despite being a company that is, I believe, 19 years old, you aren't exactly a giant company that throws bodies at problems. I believe you have seven full-time employees, two of whom have been hired in the last quarter.Kelly: That's true. So, seven full-time employees and five analysts. So, we have—of that it's five analysts, and we only added a fifth analyst the beginning of this year, with Dr. Kate Holterhoff. [unintelligible 00:08:09], kind of, bring her on the team.So, we had been operating with, like, kind of, six full-time employees. We were like, “We need some more resources in this area.” And we heard another analyst, which if you talk about, okay, we hired one more, but when you're talking about hiring one more and adding that to a team of, like, four analysts, it's such a big difference, just in terms of, kind of, resources. And I think your observation about you ca—we don't just throw bodies at problems is kind of correct. That is absolutely not the way we go about things at all.Corey: At a company that is taking the same model that The Duckbill Group does—by which I mean not raising a bunch of outside money is, as best I can tell—that means that you have to fall back on this ancient business model known as making more money than it costs to run the place every month, you don't get to do this massive scaled out hiring thing. So, bringing on multiple employees at a relatively low turnover company means that suddenly you're onboarding not just one new person, but two. What has that been like? Because to be very clear, if you're hiring 20 engineers or whatnot, okay, great, and you're having significant turnover, yeah, onboarding two folks is not that big of a deal, but this is a significant percentage of your team.Kelly: It is. And so for us—and Kate started at the beginning of this year, so she's only been here for a bit—but in terms of onboarding another analyst, this is something where I haven't done before, but, like, my colleagues have, whereas the other new member of our team, Morgan Harris, who is our Account Engagement Manager, and she is amazing, and has also, like, very interesting background and client success in, like, fashion, which is, you know, awesome when I'm trying to figure out what [unintelligible 00:09:48] fit I need to do, we have someone in-house who can actually give me advice on that. But that's not something that we have onboarded for that role very much in the past, so bringing on someone where they're the only person in their role and, like, having to begin to learn the role. And then also to bring in another analyst where we have a little bit more experience onboarding analysts, it takes a lot of patience for everybody involved. And the thing I love about RedMonk and the people that I get to work with is that they actually have that patience and we function very well as, like, a team.And because of that, I think things that could really have thrown us off course, like losing an account engagement or onboarding one and then onboarding a new analyst, like, over the holidays, during a pandemic, and everything else that is happening, it's going much more smoothly than it could have otherwise.Corey: These are abnormal times, to be sure. It's one of those things where it's, we're a couple years into a pandemic now, and I still feel like we haven't really solved most of the problems that this has laid bare, which kind of makes me despair of ever really figuring out what that's going to look like down the road.Kelly: Yeah, absolutely. And there is very much the sense that, “Okay, we should be kind of back to normal, going to in-person conferences.” And then you get to an in-person conference, and then they all move back to virtual or, as in your case, you go to an in-person conference and then you have to sequester yourself away from your family for a couple of weeks to make sure that you're not bringing something home.Corey: So, I have to ask. You have been quoted as saying that 2022—for those listening, that is this year—is the year of documentation. You're onboarding two new people into a company that does not see significant turnover, which means that invariably, “Oh, it's been a while since we've updated the documentation. Whoops-a-doozy,” is a pretty common experience there. How much of your assertion that this is the year of documentation comes down to the, “Huh. Our onboarding stuff is really out of date,” versus a larger thing that you're seeing in the industry?Kelly: That is a great question because you never know what your documentation is like until you have someone new, kind of, come in with fresh eyes, has a perspective not only on, “Okay, I have no idea what this means,” or, “This is not where I thought it would be,” or, “This, you know, system is not working in any… in any way similar to anything I have ever seen in any other part of my, like, kind of, working career.” So, that's where you really see what kind of gaps you have, but then you also kind of get to see which parts are working out really well. And not to spend, kind of, too much on that, but one of the best things that my coworkers did for me when I started was, Rachel Stephens had kept a log of, like, all the questions that she had as a new analyst. And she just, like, gave that to me with some advice on different things, like, in a spreadsheet, which I think is—I love spreadsheets so much and so does Rachel. And I think I might love spreadsheets more than Rachel at this point, even though she actually has a hat that says, “Spreadsheets.”But when Kate started, it was fascinating to go through that and see what parts of that were either no longer relevant because the entire world had changed, or because the industry had advanced, or because there's all these new things you need to know now that we're not on the list of things that you needed to know three years ago. And then what other, even, topics belong down on that kind of list of things to know. So, I think documentation is always a good, like, check-in for things like that.But going back to, like, your larger question. So, documentation is important, not just because we happened to be onboarding, but a lot of people, I think once they no longer could be in the office with people and rely on that kind of face-to-face conversations to smooth over things began, I think, to realize how essential documentation was to just their everyday to day, kind of, working lives. So, I think that's something that we've definitely seen from the pandemic. But then there are certainly other signals in the software industry-specific, which we can go into or not depending on your level of interest.Corey: Well, something that I see that I have never been a huge fan of in corporate life—and it feels like it is very much a broad spectrum—has been that on one side of the coin, you have this idea that everything we do is bespoke and we just hire smart people and get out of their way. Yeah, that's more uncontrolled anarchy than it is a repeatable company process around anything. And the other extreme is this tendency that companies have, particularly the large, somewhat slow-moving companies, to attempt to codify absolutely everything. It almost feels like it derives from the what I believe to be mistaken belief that with enough process, eventually you can arrive at the promised land where you don't have to have intelligent, dynamic people working behind things, you can basically distill it down to follow the script and push the buttons in the proper order, and any conceivable outcome is going to be achieved. I don't know if that's accurate, but that's always how it felt when you start getting too deeply mired in documentation-slash-process as almost religion.Kelly: And I think—you know, I agree. There has to be something between, “All right, we don't document anything and it's not necessary and we don't need it.” And then—Corey: “We might get raided by the FBI. We want nothing written down.” At which point it's like, what do you do here? Yeah.Kelly: Yeah. Leave no evidence, leave no paper trail of anything like that. And going too far into thinking that processes is absolutely everything, and that absolutely anyone can be plugged into any given role and things will be equally successful, or that we'll just be automated away or become just these, kind of, automatons. And I think that balance, it's important to think about that because while documentation is important, and you know, I will say 2022, I think we're going to hear more and more about it, we see it more as an increasingly valuable thing in tech, you can't solve everything with documentation. You can use it as the, kind of, duct tape and baling wire for some of the things that your company is doing, but throwing documentation at it is not going to fix things in the same way that throwing engineers at a problem is not going to fix it either. Or most problems. I mean, there are some that you can just throw engineers at.Corey: Well, there's a company wiki, also known as where documentation goes to die.Kelly: It is. And those, like, internal wikis, as horrible as they can be in terms of that's where knowledge goes to die as well, places that have nothing like that, it can be even more chaotic than places that are relying on the, kind of, company internal wiki.Corey: So, delving into a bit of a different topic here, before you were in the QA universe, you were what distills down to an academic. And I know that sometimes that can be interpreted as a personal attack in some quarters; I assure you, despite my own eighth grade level of education, that is not how this is intended at all. Your undergraduate degree was in medieval history—or medieval studies and your PhD was in English. So, a couple of questions around that. One, when we talk about medieval studies, are we talking about writing analyst reports about Netscape Navigator, or are we talking things a bit later in the sweep of history than that?Kelly: I appreciate the Netscape Navigator reference. I get that reference.Corey: Well, yeah. Medieval studies; you have to.Kelly: Medieval studies, when you—where we study the internet in the 1990s, basically. I completely lost the line of questioning that you're asking because I was just so taken by the Netscape Navigator reference.Corey: Well, thank you. Started off with the medieval studies history. So, medieval studies of things dating back to, I guess, before we had reasonably recorded records in a consistent way. And also Twitter. But I'm wondering how much of that lends itself to what you do as an analyst.Kelly: Quite a bit. And as much as I want to say, it's all Monty Python references all the time, it isn't. But the disciplinary rigor that you have to pick up as a medievalist or as anyone who's getting any kind of PhD ever, you know, for the most part, that very much easily translated to being an analyst. And even more so tech culture is, in so many ways, like, enamored—there's these pop culture medieval-isms that a lot of people who move in technical circles appreciate. And that kind of overlap for me was kind of fascinating.So, when I started, like, working in tech, the fact that I was like writing a dissertation on Lord of the Rings was this little interesting thing that my coworkers could, like, kind of latch on to and talk about with me, that had nothing to do with tech and that had nothing to do with the seemingly scary parts of being an academic.Corey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats V-U-L-T-R.com slash screaming.Corey: I want to talk a little bit about the idea of academic rigor because to my understanding, in the academic world, the publication process is… I don't want to say it's arduous. But if people subjected my blog post anything approaching this, I would never write another one as long as I lived. How does that differ? Because a lot of what I write is off-the-cuff stuff—and I'm not just including tweets, but also tweets—whereas academic literature winds up in peer-reviewed journals and effectively expands the boundaries of our collective societal knowledge as we know it. And it does deserve a different level of scrutiny, let's be clear. But how do you find that shifts given that you are writing full-on industry analyst reports, which is something that we almost never do on our side, just honestly, due to my own peccadilloes?Kelly: You should write some industry reports. They're so fun. They're very fun.Corey: I am so bad at writing the long-form stuff. And we've done one or two previously, and each time my business partner had to basically hold my nose to the grindstone by force to get me to ship, on some level.Kelly: And also, I feel like you might be underselling the amount of writing talent it takes to tweet.Corey: It depends. You can get a lot more trouble tweeting than you can in academia most of the time. Every Twitter person is Reviewer 2. It becomes this whole great thing of, “Well, did you consider this edge corner case nuance?” It's, “I've got to say, in 208 any characters, not really. Kind of ran out of space.”Kelly: Yeah, there's no space at all. And it's not what that was intended. But going back to your original question about, like, you know, academic publishing and that type of process, I don't miss it. And I have actually published some academic pieces since I became an analyst. So, my book finally came out after I had started as—it came out the end of 2019 and I had already been at RedMonk for a year.It's an academic book; it has nothing to do with being an industry analyst. And I had an essay come out in another collection around the same time. So, I've had that come out, but the thing is, the cycle for that started about a year earlier. So, the timeframe for getting things out in, especially the humanities, can be very arduous and frustrating because you're kind of like, “I wrote this thing. I want it to actually appear somewhere that people can read it or use it or rip it apart if that's what they're going to do.”And then the jokes that you hear on Twitter about Reviewer 2 are often real. A lot of academic publishing is done in, like, usually, like, a double-blind process where you don't know who's reviewing you and the reviewers don't know who you are. I've been a reviewer, too, so I've been on that side of it. And—Corey: Which why you run into the common trope of people—Kelly: Yes.Corey: —suggesting, “Oh, you don't know what you're talking about. You should read this work by someone else,” who is in fact, the author they are reviewing.Kelly: Absolutely. That I think happens even when people do know who [laugh] who's stuff they're reviewing. Because it happens on Twitter all the time.Corey: Like, “Well, have you gotten to the next step beyond where you have a reviewer saying you should wind up looking at the work cited by”—and then they name-check themselves? Have we reached that level of petty yet, or has that still yet to be explored?Kelly: That is definitely something that happens in academic publishing. In academic circles, there can be these, like, frenemy relations among people that you know, especially if you are in a subfield that is very tiny. You tend to know everybody who is in that subfield, and there's, like, a lot of infighting. And it does not feel that far from tech, sometimes. [unintelligible 00:21:52] you could look at the whole tech industry, and you look at the little areas that people specialize in, and there are these communities around these specializations that—you can see some of them on Twitter.Clearly, not all of them exist in the Twitterverse, but in some ways, I think that translated over nicely of, like, the year-long publication and, like, double peer-review process is not something that I have to deal with as much now, and it's certainly something that I don't miss.Corey: You spent extensive amounts of time studying the past, and presumably dragons as well because, you know, it's impossible to separate medieval studies from dragons in my mind because basically, I am a giant child who lives through fantasy novels when it comes to exploring that kind of past. And do you wind up seeing any lessons we can take from the things you have studied to our current industry? That is sort of a strange question, but they say that history doesn't repeat, but it rhymes, and I'm curious to how far back that goes. Because most people are citing, you know, 1980s business studies. This goes centuries before that.Kelly: I think the thing that maybe stands out for me the most the way that you framed that is, when we look at the past and we think of something like the Middle Ages, we will often use that term and be like, “Okay, here's this thing that actually existed, right?” Here's, like, this 500 years of history, and this is where the Middle Ages began, and here's where it ended, and this is what it was like, and this is what the people were like. And we look at that as the some type of self-evident thing that exists when in reality, it's a concept that we created, that people who lived in later ages created this concept, but then it becomes something that has real currency and, really, weight in terms of, like, how we talk about the world.So, someone will say, you know, I like that film. It was very medieval. And it'll be a complete fantasy that has nothing to do with Middle Ages but has a whole bunch of these tropes and signals that we translate as the Middle Ages. I feel like the tech industry has a great capacity to do that as well, to kind of fold in along with things that we tend to think of as being very scientific and very logical but to take a concept and then just kind of begin to act as if it is an actual thing when it's something that people are trying to make a thing.Corey: Tech has a lot of challenges around the refusing to learn from history aspect in some areas, too. One of the most common examples I've heard of—or at least one that resonated the most with me—is hiring, where tech loves to say, “No one really knows how to hire effectively and well.” And that is provably not true. Ford and GM and Coca-Cola have run multi-decade studies on how to do this. They've gotten it down to a science.But very often, we look at that in tech and we're trying to invent everything from first principles. And I think, on some level, part of that comes out as, “Well, I wouldn't do so well in that type of interview scenario, therefore, it sucks.” And I feel like we're too willing in some cases to fail to heed the lessons that others have painstakingly learned, so we go ahead and experiment on our own and try and reinvent things that maybe we should not be innovating around if we're small, scrappy, and trying to one area of the industry. Maybe going back to how we hire human beings should not be one of those areas of innovation that you spend all your time on as a company.Kelly: I think for some companies, I think it depends on how you're hiring now. It's like, if your hiring practices are horrible, like, you probably do need to change them. But to your point, like, spending all of your energy on how are we hiring, can be counterproductive. Am I allowed to ask you a question?Corey: Oh, by all means. Mostly, the questions people ask me is, “What the hell is wrong with you?” But that's fine, I'm used to that one, too. Bonus points if you have a different one.Kelly: Like, your hiring processes at Duckbill Group. Because you've hired, you know, folks recently. How do you describe that? Like, what points of that you think… are working really well?Corey: The things that have worked out well for us have been being very transparent at the beginning around things like comp, what the job looks like, where it starts, where it stops, what we expect from people, what we do not expect from people, so there are no surprises down that path. We explain how many rounds of interviews there are, who they'll be meeting with at each stage. If we wind up declining to continue with a candidate in a particular cycle, anything past the initial blind resume submission, we will tell them; we don't ghost people. Full stop. Originally, we wanted to wind up responding to every applicant with a, “Sorry, we're not going to proceed,” if the resume was a colossal mismatch. For example, we're hiring for a cloud economist, and we have people with PhDs in economics, and… that's it. They have not read the job description.And then when you started doing that people would argue with us on a constant basis, and it just became a soul-sucking time sink. So, it's unfortunate, but that's the reality of it. But once we've had a conversation with you, doing that is the right answer. We try and move relatively quickly. We're honest with folks because we believe that an interview is very much a two-way street.And even if we declined to proceed—or you declined to proceed with us; either way—that you should still think well enough of us that you would recommend us to people for whom it might be a fit. And if we treat you like crap, you're never going to do that. Not to mention, I just don't like making people feel like crap as a general rule. So, that stuff that has all come out of hiring studies.So, has the idea of a standardized interview. We don't have an arbitrary question list that we wind up smacking people with from a variety of different angles. And if you drew the lucky questions, you'll do fine. We also don't set this up as pass-fail, we tend to presume that by the time you've been around the industry for as long as generally is expected for years of experience for the role, we're not going to suddenly unmask you as not knowing how computers work through our ridiculous series of trivia questions. We don't ask those.We also make the interview look a lot like what the job is, which is apparently a weird thing. It's in a lot of tech companies it's, “Go and solve whiteboard algorithms for us.” And then, “Great. Now, what's the job?” “It's going to be moving around some CSS nonsense.”It's like, first that is very different, and secondly, it's way harder to move CSS than to implement quicksort, for most folks. At least for me. So, it's… yeah, it just doesn't measure the right things. That's our approach. I'm not saying we cracked it by any means to be very clear here. This is just what we have found that sucks the least.Kelly: Yeah, I think the, ‘we're not going to do obscure whiteboarding exercises' is probably one of the key things. I think some people are still very attached those personal reasons. And I think the other thing I liked about what you said, is to make the interview as similar to the job as you can, which based on my own getting hired process at RedMonk and then to some levels of being involved in hiring our, kind of, new hires, I really like that. And I think that for me, the process will like, okay, you submit your application. There'd be—I think I'd to do a writing sample.But then it was like, you get on a call and you talk to Steve. And then you get on a call and you talk to James. And talking to people is my job. Like for the most part. I write things, but it's mostly talking to people, which you may not believe by the level of articulate, articulate-ness, I am stumbling my way through in this sentence.And then the transparency angle, I think it's something that most companies are not—may not be able to approach hiring in such a transparent way for whatever reason, but at least the motion towards being transparent about things like salaries, as opposed to that horrible salary negotiation part where that can be a nightmare for people, especially if there's this code of silence around what your coworkers or potential coworkers are making.Corey: We learned we were underpaying our clouds economists, so we wound up adjusting the rate advertised; at the same time we wound up improving the comp for existing team because, “Yeah, we're just going to make you apply again to be paid a fair wage for what you do,” no. Not how we play these games.Kelly: Yeah, which is, you know, one of the things that we're seeing in the industry now. Of course, the term ‘The Great Resignation' is out there. But with that comes, you know, people going to new places partly because that's how they can get, like, the salary increase or whatever it is they want for among other reasons.Corey: Some of the employees who have left have been our staunchest advocates, both for new applicants as well as new clients. There's something to be said for treating people as you mean to go on. My business partner, I've been clear that we aspire for this to be a 20, 25-year company, and you don't do that by burning bridges.Kelly: Yeah. Or just assuming that your folks are going to stay for three years and move on, which tends to be the kind of the lifespan of where people stay.Corey: Well, if they do, that's fine because it is expected. I don't want people to wind up feeling that they owe us anything. If it no longer makes sense for them to be here because they're not fulfilled or whatnot—this has happened to us before we've tried to change their mind, talked to them about what they wanted, and okay, we can't offer what you're after. How can we help you move on? That's the way it works.And like, the one thing we don't do in interviews—and this is something I very much picked up from the RedMonk culture as well—is we do a lot of writing here, so there's a writing sample of here's a list of theoretical findings for an AWS bill—if we're talking about a cloud economist role—great. Now, the next round is people are going to talk to you about that, and we're going to roleplay as if we were a client. But let's be clear, I won't tolerate abusive behavior from clients to our team, I will fire a client if it happens. So, we're not going to wind up bullying the applicant and smacking ‘em around on stuff—or smacking them around to be clear. That was an ‘em not a him, let's be clear.It's a problem of not wanting to even set the baseline expectation that you just have to sit there and take it when clients decide to go down unfortunate paths. And I believe it's happened all of maybe once in our five-and-a-half-year history. So, why would you ever sit around and basically have a bunch of people chip away at an applicant's self-confidence? By virtue of being in the room and having the conversation, they are clearly baseline competent at a number of things. Now, it's just a question of fit and whether their expression of skills is what we're doing right now as a company.At least that's how I see it. And I think that there is a lot of alignment here, not just between our two companies, but between the kinds of companies I look at and can actively recommend that people go and talk to.Kelly: Yeah. I think that emphasis on, it's not just about what a company is doing—like, what is their business, you know, how they're making money—but how they're treating people, like, on their way in and on the way out. I don't think you can oversell how important that is.Corey: Culture is what you wind up with instead of what you intend. And I think that's something that winds up getting lost a fair bit.Kelly: Yeah, culture is definitely not something you can just go buy, right? [laugh], where you can, like—this is what our culture will be.Corey: No, no. But if there is, “Culture-in-a-box. Like, you may not be able to buy it, but I would love to sell it to you,” seems to be the watchwords of a number of different companies out there. Kelly, I really want to thank you for taking the time to speak with me today. If people want to learn more, where can they find you?Kelly: They can find me on Twitter at @drkellyannfitz, that's D-R-K-E-L-L-Y-A-N-N-F-I-T-Z—I apologize for having such a long Twitter handle—or my RedMonk work and of my colleagues, you can find that at redmonk.com.Corey: And we will, of course, include links to that in the [show notes 00:33:14]. Thank you so much for your time. I appreciate it.Kelly: Thanks for having me.Corey: Kelly Fitzpatrick, senior industry analyst at RedMonk. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment telling me how terrible this was and that we should go listen to Reviewer 2's podcast instead.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
Stephen O'Grady is a Co-Founder and Principal Analyst at Redmonk, the developer-focused industry analyst firm. Stephen is joined by Rachelle Palmer, Sr. Product Manager at MongoDB along with Michael and Nic to talk about Redmonk's latest Software Industry Language report. This report ranks language popularity using data from sites such as GitHub, and Stack Overflow. Rachelle brings her extensive experience at MongoDB, and specifically in the driver space to the conversation and we uncover and discuss some surprises from the report. You can review the report here: https://redmonk.com/sogrady/2021/03/01/language-rankings-1-21/ Join us in the MongoDB Community Forums to chat about this episode, the Language report and any thing related to MongoDB.
It's a light week. Not much going on except for me being stung by the "30 is old in tech" rebuke. What happened in the world of .NET (which turned 20 this year)? Let's get to it:
In software engineering, we often think about how the process itself, for example Agile or Extreme programming is what influences engineering culture. But what if the tools themselves are what drives developer culture and have a much bigger impact than process on engineering culture ?In this episode of the Art of Modern Ops, Cornelia Davis sat down with industry analyst James Governor of Redmonk to discuss the state of DevOps, cloud native and what really drives developers to choose the tools they use. “Sometimes technology is chosen by people based on their gut instincts rather than on facts,” says James Governor. “Of course we all view ourselves as computer scientists, but often there are more than facts involved for why people gravitate towards particular brands.” Listen to the entire episode as Cornelia and James drill down on choosing technologies, testing in production and progressive delivery.
Everything in modern tech — including observability — is actually a culture change. Observability is a different way of working, thinking, and composing a team. It is essentially a love letter to the future, helping the people who will support the application later. Instead of an operator sitting back and looking at a dashboard, observability tackles what can be done during the process of developing an application so that production can feel more comfortable. In James Governor's word, “observability is about troubleshooting.” James Governor is the co-founder of RedMonk, a developer-focused industry analyst company. After working as a tech journalist, James saw room for a new research firm with a different focus and thus RedMonk was born. Listen to this week's episode to hear James and Ben discuss the generational shift in technology building, and learn more about how observability can help developers. This week's episode is the last installment of the special three-part series on observability in data. Thank you for joining us!
Learn more:RedMonkCockroach and the Source Available FutureDataStax and the Modern Commercial Open Source BusinessThe Cloud and Open Source Powder KegWhat Does Open Mean in the Era of Cloud APIs?It's 2019. It's Still Not a Good Idea to Build Your Own PlatformFollow everyone on Twitter:IntersectStephen O'GradyRedMonkDerrick HarrisPivotal
In 2017, Rachel Stephens of Redmonk wrote a great piece about how technical debt is an incomplete analogy. But she agrees that it shouldn't be abandoned. In this episode, she and I expound on the analogy to its breaking points, including liquidity, derivatives, and the perpetual state of refinancing we're all in. See full show notes at: https://content.pivotal.io/podcasts/continuous-refinancing-of-your-tech-debt-with-rachel-stephens-of-redmonk Register for SpringOne Platform today and save an extra $200 with S1P200_DDREWITZ.
Microsoft's programming language TypeScript has quietly become one of the most popular languages among developers, at least according to a report published by the analyst firm RedMonk this week. TypeScript jumped from number 16 to number 12, just behind Apple's programming language Swift, in RedMonk's semiannual rankings, which were last published in August.
When Coté says he doesn't know how numbers work, he actually means it. To help out, he talks with Rachel Stephens, from RedMonk, who not only explains ratios, but also finance numbers. Fine more from Rachel on her RedMonk blog (https://redmonk.com/rstephens/), and in Twitter (https://twitter.com/rstephensme). Special Guest: Rachel Stephens.
Apple's programming language Swift and the Android developer favorite Kotlin are two of the fastest growing languages of all time. But that growth might be starting to slow according to a new report. The analyst firm RedMonk has tracked programmers' interest in various programming languages since 2011. During that time, Swift and Kotlin grew faster than any other language the firm tracked, including Google's Go and Mozilla's Rust.
In episode 15 of The Secure Developer, Guy is joined by James Governor, Analyst and Co-founder of RedMonk, a developer-focused industry analyst firm. The pair discusses multiple ways that companies can be incentivized, and how they can incentivize others, to invest in and improve security. The post Ep. #15, Enterprise Security with RedMonk's James Governor appeared first on Heavybit.
Apple's programming language Swift is less than four years old, but a new report finds that it's already as popular as its predecessor, Apple's more established Objective-C language. Swift is now tied with Objective-C at number 10 in the rankings conducted by analyst firm RedMonk. It's hardly a surprise that programmers are interested in Apple's language, which can be used to build applications for the iPhone, Apple Watch, Macintosh computers, and even web applications.
This week, we look at one of the new analyst models, and what they do, by way of Ben Thompson. Horace Dediu and RedMonk are other examples of this model, but Ben Thompson is the highest flying, most interesting practicer now. Ben's business model is pretty straight-forward: a partial paywall around his some of his weekly content, podcast sponsorships, and (maybe?) consulting.Also, the DC steak scene, BLT Steakhouse's odd way of cooking a steak. Brandon says to go to Charlie Palmer's.Check out the more detailed show notes and links.
Michael Coté: @cote | cote.io | Pivotal | Software Defined Talk Show Notes: 00:54 - Pivotal 04:39 - Being a Professional Muller aka Analyst 11:08 - Iterative Development 32:54 - Getting a Job as a Professional Muller aka Analyst Resources: Pivotal Cloud Foundry GemFire Greenplum Pivotal Labs Wardley Maps Software Defined Talk Episode #79: From a vegan, clothing optional co-op to working with banks and oil companies - Coté's professional life, part 1 Software Defined Talk Episode #85: Being an analyst without being an asshole - Coté's professional life, part 2 RedMonk Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode #66. I am a developer, Charles Lowell at The Frontside and also host-in-training for 65 episodes. This is my 66th and I'm flying alone this week but we do have on the show with us a very special guest. Actually, the person who taught me how to podcast, I think it was about 10 years ago and he was like, "Charles, we should do this podcasting thing." I started my very first podcast with him and I still haven't figured it out. But his name is Michael Coté and he's a fantastic guy and welcome to the show, Coté. MICHAEL: Thanks for having me, Charles. It's great to be here. CHARLES: Now, what are you up to these days? You're over at Pivotal. MICHAEL: That's right. I work at Pivotal and probably people who are in the developing world know them for Spring. We have most of the Spring people. Then we also have this thing Pivotal Cloud Foundry. We're not supposed to call it a platform as a service but for matters of concision, it's a platform as a service that's the runtime that you run your stuff in. Then we also have a bunch of data products like GemFire and Greenplum and things like that. Then, 'openymously', if that's a word, we have Pivotal Labs. Now -- CHARLES: I think, it's eponymously. MICHAEL: Eponymously, yes. Now, you might remember Pivotal Labs as the people who use Chef Scripts to configure their desktops. Remember that? CHARLES: Yeah, I remember that. I was into that. MICHAEL: Yeah, in coincidental kind of way, the inspiration for the project Sputnik thing, which is coincidentally because now Dell Technologies owns Pivotal so all of that stuff has come for a full circle. I guess also since I'm intro-ing myself, I work on what we call the Advocate Team because we don't call them evangelists. No one likes to be called that I guess. I guess there's 12 of us now. We just hired this person, also in Austin actually McNorma who's big in the Go community and apparently can make images of gophers really well. I'm sure she does many other extraordinary things, not just the illustrator master. Everyone else basically like codes or uses the terminal but I do slides. CHARLES: Well, that's your weapon of choice, right? It's a more elegant weapon for civilized time or something like that. I'm going to look it up on Wikia. MICHAEL: Yeah, basically what we do on our team is we just talk about all the stuff Pivotal does and problems that we solve in the way people in an organizations like would think to care about our stuff. Most of what I do is I guess you call it the management consultant type of stuff. Since I have a background as an analyst and I used to work on corporate strategy and M&A at Dell so I have a vantage point in addition to having programmed a long time ago. If you're changing your organization over to be more agile or trying to devops, we would say cloud-native with a hyphen. How do you change your organization over what works and doesn't work? Most people in large organizations, they sort of pat you on your head. I'm sure you encounter this. That sounds really nice that we would be doing all of the good, correct ways of using computers but we're basically terrible and we could never make that happen here. Thanks for talking with us, we're going to go back and stew in our own juices of awfulness. You've got to pluck them out of that self-imposed cannibal pot there in the jungle and show them that they actually can improve and do things well. CHARLES: Would you say you feel like your job is being that person who shakes them away and can be like, "Good God! Get a grip on yourself!" MICHAEL: Sure. That's a very popular second or third slide in a presentation -- the FUD slide, the Fear of Uncertainty and Doubt slide where you're basically like, "Uber!" and then everyone just like soils their pants because they're afraid that are like Airbnb and Uber and [inaudible] and Google is going to come in and, as they say, disrupt their state industry. I try not to use the slides anymore because they're obnoxious. Also, most people in large organizations nowadays, they know all of that and they've already moved to putting on a new pair of pants stage of their strategizing. CHARLES: You've got the kind of the corporate wakeup call aspect of it but then it's also seems like a huge component of your job which is when you were at RedMonk, when you were at 451 and even to a lesser extent, it was Dell who was paid well to just kind of mull it over, like just kind of sit there and asynchronously process the tech industry, kind of like organizational yeast and let it ferment, kind of trying to see where the connections lie and then once you've made that presented, do you think that's fair? That's what sprung to mind when I heard you say like, "Yeah, we just kind of sit around and think about what is Pivotal and what does it do and what's it going," but like how do you get that job of like, "I'm just kind of a professional muller." MICHAEL: That's right. First of all, I think professional muller is accurate, as long as, I guess mulling is also for -- what's that thing you drink at Christmas that you put the little -- CHARLES: Mulled wine. Like low wine. MICHAEL: I can feel like that sometimes late at night. But having a job as an analyst, I was an industry analyst at two places for a total of about eight years or so. Then as you're saying doing strategy at a company, now what I do here, essentially a lot of what you do is very difficult. I know it sounds to people. You just read a lot of the Internet. You just consume a lot of the commentary and the ideas of things that are going out there and you try to understand it and then synthesize to use that cheesy word. Synthesize it into a new form that explains what it is and then finally, the consultant part comes in where you go and meet with people or you proactively think about what people might be asking and they say something like, "What does this mean for me? And how would I apply it to solve my problems?" I guess as an example of that -- I apologize for being a little commercial but these are just the ideas I have in my head -- Ford is a customer of ours and they also have invested in us which is kind of novel. We have GE and Ford invested in Pivotal and Microsoft and Dell Technologies as an interesting mix but anyways, they have this application called the Ford Pass Application. I drive a Ford Focus -- CHARLES: Like Subaru? But you do drive a Ford. MICHAEL: Yeah, because I don't care about cars. It's a bunch of nonsense. I see this app and basically the app, if you have a more advanced one, it might tell you your mileage and even like remotely start your car. But it doesn't really do that much. You have the app and it will tell you information about your car and where to park and it even has this thing where it links to another site to book a dealership thing, which is annoying. CHARLES: Why would you want to book a dealership? To buy another car? MICHAEL: Well because the Ford Focus I have is notorious for having transmission problems so you're like, "I got to go and take it into the dealer to get all this recall stuff taken care of," so wouldn't it be nice... I don't know if you've ever worked with a car dealer but it's not desirable. CHARLES: Yeah, it would be nice if they didn't charge $6000 for everything. MICHAEL: Right. It's a classic system of having a closed market, therefore that jacks up prices and lowers customer service usually. What's the fancy word if there is a negative correlation, if you were to chart it out? Like price is negatively correlated to your satisfaction with it. Kind of like the airline industry, not to bring up a contemporary topic. You pay a lot of money to fly and you're like, "This is one of the worst experiences I've had in my life," whereas you go to the dentist and get a root canal and you're like $20 co-pay. Loving it. [Laughter] MICHAEL: Anyhow, this Ford Pass application doesn't really do very much so what does that mean for what I was explaining. If you go look up and read about it, starting back in the late-90s, your extreme programming and then your Agile Software Development and your devops nowadays, one of the major principles is what you should do is ship often. Maybe you should even ship every week or every day. Don't worry about this gigantic stack of requirements that you have and whatever you should be shipping all the time and then we've trained ourselves to no longer say failing fast. That was a fun cheeky thing back in the late-2000s. CHARLES: Did we trained ourselves not to say that anymore? MICHAEL: I don't hear it very often. CHARLES: Man, I got to go scrub my brain. MICHAEL: Yeah, well this is why you consult with me every 10 years as I tell you the new things. CHARLES: Okay, here we go. We're going to have you on the podcast again. MICHAEL: That's right. You have this idea of like, "We should be releasing weekly," but then if you go to Ford, you're like, "What does that mean?" To shave the shaggy dog here, essentially the idea that they're shipping this mobile application that doesn't really do very much is an embodiment of the idea that they should be shipping more frequently. This may be a stupid example. It's not that it's not going to do very much like permanently but as I have witnessed, very frequently they add new features so Ford is in this cadence but there's this app that instead of working on an application for two years and having everything in it, they're actually releasing it on, I don't know if it's weekly but they're releasing it on a very frequent basis, which allows them to add features. What that gets you is all the advantages of a fast iteration cycle small batch thing where they can study this actually a good feature. They can do all your Lean Startup nonsense. That's a very like weird, perhaps example of how you explain to someone like a large car manufacturer like Ford, this is what devops means for you. Therefore, why you should spend a lot of money on Pivotal? Now that's the part that lets me pay my mortgage every month, the last bit there. CHARLES: Right so Pivotal builds apps. MICHAEL: Well, the Labs people build apps for you. CHARLES: I'm kidding Coté. MICHAEL: Yeah, they actually do. The Labs people are like a boutique of another boutique like ThoughtWorks is kind of a boutique but they're kind of a boutique-y version of ThoughtWorks. That probably is terrible as someone who markets for Pivotal to do that. Do you ever notice how political candidates never really name their opposition? Like you never really want to name your competition but anyways... CHARLES: Pivotal marketing are going to come crashing through your window. Everybody, if we hear them in the next five seconds -- well, I guess you can't call 911 because this is not live. MICHAEL: Yeah, that's true. The Labs people build stuff for you and then the part that I work, in the Pivotal Cloud Foundry people, they have the actual runtime environment, the cloud platform that you would run all that stuff. Plus all the Spring nonsense for your microservices and your Spring Boot. I understand people like that. CHARLES: So good for Ford, for actually being able to experience, either in the development and the joys and the benefits that come with it. But this is actually something that I actually want to talk about independently was as I kind of advance in my career, I find myself pushing back a little bit against that incredibly tight, iterative schedule. Shipping things is fantastic and it's great but I find so much of my job these days is just trying to think out and chart a course for where those iterations will carry you and there is a huge amount of upfront design and upfront thought that it is speculatory but it's very necessary. You need to speculate about what needs to happen. Then you kind of measure against what's actually happening but I feel that kind of upfront design, upfront thought, we had this moment we're like, "We don't need that anymore. Let's throw it all in the garbage." In favor of doing things in these incredibly tight loops and finding where's the clutch point, that kind of long range thinking and long range planning comes and meets with the iterative development. I have no idea. What's the best way for those to match up those long cycles and those short cycles? Where is the clutch play? MICHAEL: I'll give you two and a half, so to speak trains of thoughts on that. One of them is I think -- CHARLES: Two and half trains of thought, I like that. Can we get straight to the half train of thought? MICHAEL: Yeah, I'm going to start with the half, which is just taking all of your questions and putting periods at the end of them before I round up to answering the question. I think a lot of the lore and the learnings you get from the Agile world is basically from consultants and teams of consultants. Necessarily, they are not domain experts in what they're doing so their notion is that we're going to learn about what it is we're doing and we don't actually know we can't predict ahead of time because we're not domain experts so they almost have this attitude of like, "We'll just figure it out on the job." Let's say The Frontside gets hired to go work on a system that allows the Forest Service to figure out which trees to go chop down or not -- CHARLES: If you're the Forest Service, we are available to do that. MICHAEL: I'm guessing you don't have a lot of arborists who have 10 or 20 years of experience working there. CHARLES: No, we don't. MICHAEL: And so you have no idea about that domain so in doing an iterative thing, you won't be able to sit down and predict like everyone knows that when you send the lumberjacks out, they're going to need these five things so we're going to have to put that that feature on there. They need to be able to call in flapjacks when they run out. That's just what's going to happen so you don't know all of these things they need to do so you just can't sit down and cogitate about it ahead of time. Also this comes in from the Lean Startup where there's a small percentage of software that's actually done globally and the notion of a Lean Startup is that when you're doing a startup, you're never going to be determined what your exit is, how you cash out, whether that's building a successful long term company while you get sold to someone or whether you IPO, you're not going to able to predict what that business model is so you just need to start churning and not think a lot ahead of time. Now, the problem becomes, I think that if you are a domain expert, as you can do the inverse of all the jokes I was just making there, you actually can sit down and start to predict things. You're like, "We know we're going to need a flapjack service," so we can predict that out and start to design around that and you can do some upfront thinking. Now similarly, developers often overlook the huge amount of governance and planning that they do for their own tools, which I know you're more cognizant of being older or more experienced, as they like to say. But basically, there's a bunch of, as we used to call it when I did real work and develop stuff, iteration zero work like we're going to need to build a build system, we're going to need a version control. You actually do know all these things you're going to need so there are all the things you can plan out and that's analogous to whatever domain you're working in. Sometimes, at least for your toolchain, it is worth sitting down and planning out what you want. Now, to hold back the people who are going to crash in my window, one of the things you should consider is using Pivotal Cloud Foundry. That's probably something you should cogitate on ahead of time. CHARLES: I think they're going to crash through your window and give you a Martini, if the marketing ninjas are going to do that and if you mention them in a positive light. MICHAEL: You know, it's 10:52 Central but if we were in London, it would probably be an appropriate time so we'll just think about that. Now, on the other hand, you don't want to go too overboard on this pre-planning. I'll give you an example from a large health insurance company that I was talking with recently. They had this mobile app -- it's always a mobile app -- that had been languishing for 15 months and it really wasn't doing anything very interesting. It was just not working well and they could never release it. This is a classic example of like, "We took a long time to release a mobile app and then we never released it again and then it blows." It's not achieving all of the business goals that we wanted. Mostly, what a health insurance company -- I've talked with a lot of the health insurance companies -- want with their mobile app is at least two things and probably many more but these would be the top of the list. One, they want their customers, their users to look up what their health insurance is, figure out doctors they can go to, the basic functioning that you expect from your health insurance company. And two, they want to encourage their customers to do healthy behaviors because if you think about it as a health insurance company, health insurance in my mind is basically like this weird gamble of like, "I'm gambling on the fact that you are going to be healthy," because then I pay out less to you and you just give me money so the healthier that your users can be, the more profit you're going to make. That's why they're always trying to encourage you to be healthy and stuff like that. The mobile app was not achieving, at least these two, if not other business goals they have. They basically were rebooting the effort. The way they started off is they had -- I don't know how many inches thick it was -- a big, old stack of requirements and the first few iterations, the product team was working on it and talking with the business analyst about this and going over it and what they sort of, as we were calling Pivotal Labs the product owner but the person who runs the team, realize is like -- to cut a long story short -- "This is kind of a waste of time. We shouldn't just prioritize these 300 features and put them in some back road and execute on them because these are the same features that we based the more abundant application on, we should probably just start releasing up the application," kind of like the FordPass app. That said, they did have a bunch of domain experience so they had a notion of basically what this app was going to do and they could start planning it out but they figured out a good balance of not paying attention to, as Martin Fowler used to call it the almighty thud, of all the requirements. What they ended up doing is they basically -- CHARLES: What's the almighty thud? MICHAEL: You know, he's got some bleaky or whatever. It's basically like we started a project and I think it's from 2004 and someone FedExed me about 600 pages of an MRD or whatever and I put it down on my table and it made a loud noise so he calls that the 'almighty thud', when you get this gigantic upfront requirement thing. What happened in this health insurance thing is they stopped listening and talking with those people and they kind of like chaff them out, not like when your rub your legs together but they kind of distracted them to that fact but eventually, they just got them out of the cycle and they started working on the app. Then lo and behold, they shipped it and things are working out better now. CHARLES: Hearing what you're saying and kind of thinking it over, I think if you're going to have an almighty thud, what you really want is you want all that upfront research and all that upfront requirements gathering or whatever, not necessarily to take the form of a set of features or some backlog of 300 things that the app 'needs' to do or 'should' do but just a catalogue of the problems, like a roadmap of the problems. MICHAEL: Exactly. CHARLES: You know, that actually is very valuable. If it's like, "These are things that are true about our users and these are the obstacles that they face. If we do choose that we want to go from Point A to Point B, where we are at Point A, then we actually have a map of what are the things that are sitting in front of that and what are the risks involved." It's like if you got -- you played, you're from my generation, you play the Oregon Trail, right? MICHAEL: Yeah. "You have dysentery." CHARLES: Right. I don't know where I'm going with this analogy but my point is developing that app is like going from Kansas City to Portland. But the thing about software is you don't necessarily have your corn meal. You don't need to say like, "We're going to need six pounds of cornmeal and we're going to need these wagons and we're going to need these mules," because this is software and you can just code a mule if you need it. But you might not need a mule, if the rivers are not in flood... I don't know. Like I said, I don't know where I'm going with this analogy. But do you see what I'm saying? The point I'm trying to make is that having the map of the Rockies and where the passes are is going to help you. MICHAEL: Yeah, this is probably where I'm supposed to expertly rattle off what Wardley maps are and how they help, which is fine. I think that's a great tool. There's this guy Simon Wardley and he's actually a great contemporary philosophizer on IT-led strategy. I think he works for CSC who no longer owns mercenaries but they used to -- Computer Science Corporations. I think they own a little bit of HP Services Division but he works for some think tank associated with CSC and he has got a couple of OSCON talks on it, where it's called a Wardley map and it's a way that you start figuring out what you're saying, which is to say your company's strategy. Using your front metaphor of the era of tall hats, if you remember that other movie, if you're on the Oregon Trail, broadly your strategy is -- and people get all up in your face about the difference between a plan and a strategy and we'll just put mute on them and edit them out of the audio because they're very annoying -- CHARLES: We'll call it an approach. MICHAEL: That's right. Your plan or your strategy -- and pardon me if I use these phrase free and loosely and everything -- is you would like to get to Oregon and you would like to live there and maybe grow apples or start a mustache wax company or some donuts, whatever it is you do out there once you get to Oregon and their strategy is -- what are the assets that I have. I have a family, I have some money and I also know some people who are going there so I'm going to buy a stagecoach and a mule, then I'm going to kind of wangle it out and we're going to go over there. Also, part of our strategy is we're going to go through the northern pass because we're used to winter versus the southern pass, which isn't the Oregon Trail because reasons. Maybe Texas isn't part of The Union yet so I don't want to deal with the transition between whatever that weird Texas thing down there -- CHARLES: The desert, there's the southwest and the desert. MICHAEL: I don't have the capabilities to survive in a desert so I need to go to the north and hopefully I won't be like that movie and have a grizzly bear rip up my backside and everything. You sort of put together this plan. Now going back to what you would do in IT world is to your point, someone does need to define what we would call the business value or the strategy, like what you want to do. Looking at the Ford thing, what Ford wants to do is they do cogitating thing ahead of time and they're like, "We manufacture cars," and you've got electric cars and Uber. That's where the scarce light comes in. In the future, who knows that people will still buy cars? It might be like that I-Robot movie where all the cars are automated and you just go into one. As a company, whose responsibility is to be as immortal as possible, we need to start making plans about how we can survive if individuals no longer buy cars. Let's do that. This is a huge upfront notion that you would have and then that does trickle down into things like my Ford thing -- I'm kind of speaking on their behalf -- if we have a direct connection with people, maybe eventually we introduce an Uber-like service. You can just check-out a Ford car. Then maybe this and maybe that. It's the strategy of how do we set ourselves up to do that. Now, I think the Agile people, what they would go for is it's really good to have that upfront strategy and you'll notice that in a lot of lean manufacturing in Agile talk, no one ever talks about this stuff, much to my extreme annoyance. They don't ever talk about who defines the strategy and who defines that you're working on this project. That's sort of left as an exercise to the reader. The Agile people would say like, "The implementation details of that are best left to the development team in an Agile model." Just like the developers are always arrogantly are like, "Hey, product manager. How about you f-off about how I should implement this? I am the expert here and let me decide how I'm going to implement the feature that you want for me." It's kind of like that rushing dolling down of things. To the development team, you worked on some, what was it? Band frame wire thing, a long time ago? It was basically like, "We don't know it. Maybe this is not the case. Let's pretend like it was." We don't know exactly how you're going to implement this stuff but our goal is that there's bands and they need sides and ways of interacting with their users so let's just figure out what that looks like but they had that upfront idea of ways that they were doing things. CHARLES: Let's start walking. MICHAEL: To add on some more. There's another edge case that you're making me think of, which is a good way of thinking through almighty thuds versus how much planning you have and that's government work. Government work that's done by contractors and especially, military contracting work. What you notice in government work is they have, seemingly way too much paperwork and process. They literally will have project managers for project managers and the project managers have to update how the project is going and they reports. If they don't do the reports correctly, their contract is penalize and you might even get fired for doing it. If anyone stops and says while the software is working, they were like, "No, no, no. don't be naive. It doesn't matter if the software is working or not, if we don't fill up the project report, we're fired." Until someone like yourself or me, it's just like your head explodes and you're like, "But working software, not a concern." In that case, it actually is part of the feature set, part of the deliverable is this nauseating amount of project reporting and upfront requirements, which has this trickle-down effect of annoyance but that's what you're getting paid for so that's what you do and if you want to make yourself feel better about it. I don't know how it is in the rest of the world but in the US, basically we think the only person worse than maybe, Lucifer is the government. I don't know why this comes about. We enjoy the fruits of the government all the time but for some reason, we just think they're awful. Whenever we give money over the government, we want to make sure that they're spending it well and if they're not corrupt and they don't hire their entire family to help them run the government and make sure that they're making extra money globally in their businesses, I wouldn't know anything about that. But essentially, you want to make sure there's no corruption so transparency is almost more important than working software. The way you achieve that transparency is with all this crazy documentation. CHARLES: Here's the thing. I agree the transparency is fantastic but nothing is more transparent than working software. Nothing is more transparent than monitored software. Nothing is more transparent than software whose, by its very nature is radiating information about itself. You can fudge a report but you can't fudge a million happy users. MICHAEL: Don't get me wrong. I'm not saying that the way that things currently operate is the ideal state. I'm saying that that desire for transparency has to be addressed and for example, using your example, let's say you were delivering working software but you were also skimming 20% off the top into some Swiss bank account -- you're basically embezzling -- and then it turns out that you need 500 developers but you only actually had 30 developers. There was corruption. The means even though the ends, even though the outcome was awesome, the means was corrupt so that's the thing in a lot of government work that you want to protect against. I just bring that up as an edge case so a principle to draw from that, when it comes to almighty thudding is like sometimes, that is part of the deliverable. We would aspire in our fail, fast, Agile world to not have a bunch of gratuitous documentation as part of the deliverable because it seems like a waste. It would be like every morning when you battle with your kids to get their shoes on, you had to write a two-page report about how you're getting ready to go to school stuff with your kids was going. As a parent you would be like, "I don't need that." However, maybe if you were like an abusive parent and it was required for you to fill out a daily status report for you to retain the parentship of your kids, maybe it would be worth of your time to fill out your daily status report. That was an awfully depressing example there. CHARLES: Let's go back to the Oregon Trail. What I'm hearing is that -- and we will take it back to the Oregon Trail -- you also need to consider, as were saying, you have some sort of strategy which is we want to go sell apples and moustache wax. But what we're going to do is we're just going to start walking, even though we don't have a map. But obviously, if you send out scouting missions, like you know where you're going, you know the West Coast is out there somewhere, you start walking but the stakes determine how much of your resources you spend on scouting and map drawing -- MICHAEL: Yeah. My way of thinking about strategy and again, people strategy is this overloaded word. But my way of thinking about strategy is you establish a goal: I would like to go to the West Coast. Now, how you figure that out could be a strategy on its own, like how did you figure out you want to go to the West Coast. But somehow, you've got to get to a prime mover. Maybe those tall hat people keep beating me up so I want to go to the West Coast. I want to go the West Coast is the prime mover. There's nothing before that. Then you've got to deal in a series of constraints. What capabilities do I have, which is another way of saying, what do I not have? And what's my current situation and context? On the Oregon Trail thing, you might be like, "I have a family of seven. I can't just get a horse and go buy a pack of cigarettes and never show up again." I guess I could do that. That's probably popular but I, as an individual have to take this family of six other people. Do I have the capabilities to do that? How could I get the cash for it? Because I need to defend against all the madness out there, I'm going to need to find some people to meet with. You're thinking and scenario planning out all of this stuff and this gets to your point of like, "If you're going to Oregon, it probably is a good idea to plan things out." You don't want to just like the next day, just figure it out. [inaudible] tell a joke. It's like, "Why do they sell luggage at the airport? Is anyone is just like, 'Screw it. Pack a clothes and we'll sort it out at the airport.'" It's an odd thing to sell at the airport. But you do some planning and you figure out ahead of time. Now, to continue the sort of pedantry of this metaphor, the other characteristic of going to the Oregon Trail, unless you're the first 10 people to do it is hundreds, if not thousands of people have done it already so you kind of know what it's going to be like. It's the equivalent, in a piece of software, if they were like, "This application is written in COBOL. I want you to now write it in --" I don't know, what are the kids do nowadays? Something.io? I-want-you-to-write-this-in-a-hot-new-language.io and basically just duplicate it. You're going to still have to discover how to do things and solve problems but if the job is just one-to-one duplicate something, then you can do a lot more upfront planning for it. CHARLES: While you're doing it, making the Uber and Airbnb. MICHAEL: Yes. CHARLES: Then you're done. MICHAEL: I think that's the truth and I want to put it another way. We used to be down here in Texas, the way we run government here is just lovely but we used to have this notion of a zero-budget, which is basically like, "Assume I'm going to give you nothing and justify every penny that I'm going to give you." I think that's a good way to think about defaults. I mean, about requirements is default is you don't need any and only get as many requirements as you need. If you're building tanks or going to the Oregon Trail, you might need a lot of requirements upfront that are actually helpful. CHARLES: But like a suit, you're just going to just strike out naked walking with. MICHAEL: That's probably a bad idea unless you -- CHARLES: Yeah, that is a bad idea but that's the bar but what happened if I were to do that? I might make it for 20 miles. MICHAEL: And build up from there and then have all the requirements that you need. I'm sure when Lewis and Clark went they were like, "We're going to need a quill and some paper and maybe a canoe and probably some guns and then let's see what happens." But that was a whole different situation than going to establish Portland. CHARLES: That was an ultimate Agile move. That was a pretty Agile project. They needed boats, they built them but they didn't leave St Louis carrying boats. MICHAEL: Right and they also didn't have a family of six that they needed to support and all this kind of stuff, right? CHARLES: Uhm-mm. MICHAEL: There was a question you asked a long time ago, not to steal the emceeing for you -- CHARLES: I would say, we need to get onto our topic -- MICHAEL: Oh, yeah. Well, maybe this is a good saying, what you're asking is, "How do you get this job?" and I don't think we ever addressed that. CHARLES: Yeah, that's a great question. You said you had to consume a lot of stuff on the internet. MICHAEL: Right. That's definitely how I do the job but I think how I get the job, there's an extended two-part interview with me on my Software Defined Talk Podcast Episode, available at SoftwareDefinedTalk.com, where I talk about my history of becoming an analyst and things like that but the way it happened is I don't have any visible hobbies, as you know Charles except reading the stuff in the Techworld. I would read about what's happening in the Techworld and would blog about it back in 2004, 2005 and I was discovered as it were by the people at RedMonk. I remember for some reason, I wrote some lengthy opinion piece about a release of Lotus Notes. I don't know why but that was a good example. This is back when all of the programming job were going to be off shored and I thought it was imminent that I was going to lose my job. I was looking for a job and I shifted over to being an analyst. That like the way that you get into this kind of business is you establish, there's two ways -- CHARLES: You established expertise, right? MICHAEL: Yeah, which is like always an unhelpful answer because it's sort of like, I was joking about this in another podcast, it's like Seth Godin's advice about doing good marketing, which is the way you do good marketing is you have an excellent product. If you have an excellent product that everyone wants to buy, then your marketing will take care of itself. I think if I'm asking how to market, I'm trying to figure out how to market a bad product. That's really what people want. CHARLES: That's also just not true. That's just like flat ass not true. That's a lie. MICHAEL: I mean, people who want to know how to diet better are not already healthy and dieting successful. You can't start with the base assumption of things are going well. CHARLES: Well, it is true. I like to think that we have an excellent product. We sell an excellent product but the thing is you can just sit on your excellent product all day and you have to tell people about it. If you want them to come sample it and try, maybe eventually buy it like the advice that you just need an excellent product. I'm amazed at anyone who can actually can say that with a straight face. MICHAEL: Well, he only writes like 150-word blogpost. I think his point is that you should aspire to have a unique situation and then marketing is easier. Similar with everyone's favorite example like an Apple or like a Pivotal or a ThoughtWorks. We eat all three of us and yourself as well, once someone gives you the benefit of the doubt of listening, you can explain why what you have is not available anywhere else. CHARLES: What it boils down to is if you want to easily differentiate, allow people to differentiate your products from others, then be different. That's fair. I'll give -- MICHAEL: To summarize it, it begets more of the tactics of how one gets a job like I do. What's the name of the short guy in Game of Thrones? 'Tyrian'? 'Tyran'? 'Tyron'? CHARLES: Tyrion. MICHAEL: At one point, Tyrion is like, "I do two things. I know things and I drink," so that's how you get into this type of business as you establish yourself as an expert and you know things. Now, the third thing which I guess Tyrion was not always required to do is you have to be able to communicate in pretty much all forms. You need to be good at written communication, at verbal communication, at PowerPoint communication, whatever all the mediums are. Just knowing something is not very useful. You also have to tell people these things. CHARLES: I think Tyrion is pretty good at that. MICHAEL: Yeah, that's true but he doesn't ever write anything. There is no Twitter or things like that. CHARLES: I feel like [inaudible] been a pretty big deal in the blogosphere. MICHAEL: Sure, no doubt. The metaphor kind of breaks down because the lattice for the continuing counterarguments do not exist in the Game of Thrones universe but whatever. CHARLES: They've got the ravens. That's like Twitter and it's bird. MICHAEL: That is true. Knowing how to deploy a raven at the right time, with the right message is valuable. CHARLES: We buffer up our ravens so that they fly right at eleven o'clock. MICHAEL: That's true. I could be convinced otherwise. CHARLES: That's why they arrived both at 6PM in the Westeros -- MICHAEL: I guess true to the metaphor of a tweet, most of the communications in Game of Thrones is either, what are they called? Little Birds? That the [inaudible] always has and then the Big Birds. You've got to tweets and the blogs. CHARLES: This is like it's nothing but Twitter. MICHAEL: Exactly. You got to really communicate across mediums. Now that the other thing that's helpful and you don't necessarily have to do this but this is what I think gets you into the larger margin. The more profitable parts of the work that I do is you have to be able to consult with people and give them advice and consulting is largely about, first figuring out the right opportunity to tell them how they can improve, which usually is it's good if they ask you first. I don't know about you but I've found that if you just pro-offer advice, especially with your spouse, you're basically told that you're a jerk. CHARLES: Well, it'd be like a personal trainer and walking around me like, "Hey man. Your muscle tone is kind of flabby. You got to really work on that." MICHAEL: The line between a good consultant and being overly-explain-y is difficult to discern but it's something that you have to master. Now, the other way you consult with people is you study them and understand what their problems are and you're sympathetic to them and I guess you can be like a British nanny and just scold them. That's a certain subset of consulting. CHARLES: Don Rickles of consulting? MICHAEL: That's right. You just help them understand how all of this knowledge that you have applies to them and hope solve their problems like the FordPass thing. When I went from being a developer to an analyst, it was a big risk to take on. I think I probably took like a $30,000 pay cut and I went from a big company health insurance to being on a $10.99 and buying your own health insurance which a whole other conversation. We talked about that every now and then but like it's a risky affair. It's not a promotion or even a lateral move. It's just an entirely different career that you go into. Then you talk with people a lot. As an analyst, you're constantly having to sort out the biases that you have with vendors who want to pay you to save things versus end-users who want to hear the truth. You can't really see a lot of Gartner and Forrester work but the work that you can see publicly from people like RedMonk, it's pretty straightforward. CHARLES: Yeah it is and whatever they did, a piece that was for one of their clients, there was always a big fat disclaimer. MICHAEL: Now, the other thing I would say is what I've noticed -- not to be all navel-gazing -- about myself and other people who are successful at whatever it is I do is there's two things. One, they constantly are putting themselves out there. I remember and this is probably still the case. This is probably all in Medium. There's probably a Medium post every quarter that's like, "If you're a developer, how do you give more talks. What your first conference talk?" Basically, the chief advice in there, other than bring business cards and rehearse is essentially like you just got to get over that idea of self-promotion. You basically have to self-promote yourself incessantly and do all those things that you find nauseous and be like, "Me, me, me," which is true. You've got to get over that thing. If you're like me and you're an introvert who actually doesn't really like that many people, except a handful of people like yourself that I'm friends or family with, you have to put on the mask of an extrovert and go out there and do all this extrovert stuff or you'll fail. I shouldn't say you'll fail, you won't increase your overall comp and margin and everything. You'll basically bottom out at about $120,000 a year or so because that's about as much as anyone will pay for someone who just write stuff but doesn't actually engage in the world and consult. You've got to do that. Then the other consequence of that is you always have to be trying out new types of content and mediums like here we are in a podcast. Long ago, you and I, in 2005 or 2004 -- CHARLES: You got me to sign up for Twitter. MICHAEL: Yeah, like we started off a podcast because I remember hearing the IT conversation stuff and John [inaudible], who is a big inspiration for me, a role model, I remember he was just trying out podcast and I was like, "All right. I'll try that out. That looks like fun," and then here we are. CHARLES: I remember you tried out the podcast and you're like, "Let's go into your backyard or my backyard. Let's talk about software for 15 minutes." I remember that very clearly and that was 12 years ago. Then I remember also like with Twitter, you're like, "Now, you should sign up for this Twitter thing," and I remember I did and that's when it was still coming through SMS on your phone and like "I'm walking around Teatown Lake. I'm going to get tea." And I was like, "Oh, my God. This is so fucking stupid." But little did I know, you were actually signed me up to a service that changed my life. MICHAEL: Yeah, it was the stage direction era of Web 2.0 where you're just supposed to give people your status updates, instead of your searing insights. But yeah, you've tried it all these different mediums because again it goes back to your job is to communicate. You need to tell people things that you know. CHARLES: Coté, what is your strategy on virtual reality? MICHAEL: My strategy in virtual reality. Well, you've caught me, Charles because I'm not into that. You remember when Time Magazine had that Chinese lady who was like a... Not Frontside. What was the name of the big virtual reality thing that was big...? CHARLES: Second Life. MICHAEL: Second Life, who is a Second Life millionaire. CHARLES: Yeah, she had armies of people. She was mining some resource in Second Life and then reselling it and she made a lot of money. MICHAEL: I don't really like visual mediums so as Marshall McLuhan would say 'hot mediums'. I guess I like the cool mediums. That's not my thing. That's where my principle fails. Maybe I'll do that one day. CHARLES: This is pretty hot. This medium is pretty like -- MICHAEL: I think maybe audio broadcast is hot. I'm just pretending like I know. This is another trick that you can deploy that my wife has picked on is most of the time, 78% of the time, I actually have no idea what I'm talking about. I just know words. I don't actually know Marshall McLuhan theory. I read that one book a long time ago and I remember that scene in Annie Hall where he gives a little diatribe to whatever the Woody Allen character is. That's the extent of my Marshall McLuhan knowledge. CHARLES: Was Marshall McLuhan actually in Annie Hall? MICHAEL: He was. CHARLES: Don't sell yourself short, Coté. MICHAEL: Sure. CHARLES: You know things and you drink so let's talk about that second aspect because I know that you like me whole tearing up as a role model. MICHAEL: I should say since we're both happily married, except for the third thing that he does which he -- CHARLES: Oh, right. MICHAEL: Another unmentionable word. He too freely hangs out with the ladies. CHARLES: Right, anyway aside from that, throughout doing all this stuff, you keep a very, very chill perspective on things. I feel like the tech world gets so wound up around itself and it gets so tight and so stressed about its own problems. There's constantly wars in JavaScript and before we were in the JavaScript world, we were warring in Ruby. I remember when Twitter went over to using Scala instead of Ruby. Oh, my goodness, it was terrible times. I feel like there's a lot of stress and yes, you want to take it seriously but I feel like you've always been able to maintain an even-keeled perspective about technology which actually allows you to commentate on it effectively and intelligently because you're able to unwind yourself from the squabbles of the day and see maybe a bigger picture or something like that. MICHAEL: That's nice of you to characterize me to use a -- is that a hanging, dangling participle there, when you're in [inaudible]? CHARLES: Yeah, I don't know. MICHAEL: I think that's also just a function of being old. CHARLES: So are you actually not stressed or is it just part of your persona of being an extrovert or something like that? MICHAEL: About the tech world? No, I'm not stressed about that. As you kind of outlined, especially I was not sent the demographics for the show, which is fine. I'll overlook that but I'm guessing that that was a joke. CHARLES: Who got some designers, developers -- MICHAEL: I'm guessing there's a lot of people who actually are on the frontlines of working on software. I think this happens also in the white collar set. But essentially, it's really easy to slip into over allegiance to something and I don't know what rhetorical fallacy this is but it's the bias of over allegiance to something, you get all wrapped up in defending a tool over something and the virtue of it, whether it's Emacs and vi. I'm sure reactive people, whatever that is, have all sorts of debates. The thing is when you're heads down on this stuff, you don't realize how petty all those discussions are. It's not so much that it's a waste of your time but it's just one battle in an overall war that you have. It's good to have opinions and figure things out but you should just relax about it because the more angry and emotional you get, you're going to make a lot of mistakes and decision and problems. I wish I had an example of this but this is one of those things that intuitively as you ages as developer, it's not like your literal age. It's just the amount of time you've been developing software. You could be a 25-year old who's been developing software for 10 years and you would probably get this notion but you just realize that stuff changes and you just learn the new things. It's kind of not a big deal like one day, you're going on and on about how vi is great and the next day you're using that Atom editor and then whatever and you just use the tool that's appropriate and it's annoying when you're younger and people are applying Hacker News with like, "You should use the tool that is appropriate," which is a stupid reply. That's just kind of how it is. Also the other thing, in the more white collar world, as an analyst, especially doing strategy for a company, you can't be biased by things because then you'll make poor decisions as an analyst. Also when you're doing strategy in M&A that result in bad business outcomes so you actually be very unbiased about things. CHARLES: I think it applies in everything. If you get too emotionally invested in one particular approach in software, literally in anything you do, it does result in bad outcomes. The problem is you may not actually realize the consequences of those bad outcomes far down the road from the poor decision that you made that caused you that outcome so you might not necessarily connect it back. MICHAEL: Yeah, and I keep bringing this up but I think another effect of being calmer in your nerd life is having something that you do outside of your programming life, which is either having a family or having hobbies or something like that but you know -- CHARLES: Or having a wild turkey. MICHAEL: Yeah but you've got to have something, a reason to stop thinking about your tech stuff or it'll consume you. I suspect when you see the older graybeards who go on and on about open source and they're very like... I don't know. What's the word? They're very over the top and fervent about tech stuff. It's probably because like me, that's their only hobby and they haven't figured out how to how to control it. It becomes part of their identity and it defines them and then they're down this twisty, turny path of annoyance to the rest of us. CHARLES: Again, don't sell yourself short, Coté. You've got plenty: you love the cooking and eating and the drinking so close this. Do you have a favorite drink that you've been mixing lately? MICHAEL: No. CHARLES: Or any kind of favorite food because every time I go over to your house, even if we're having pizza, there's always a nice hors d'oeuvre or something to drink, something to tweak that appetite for something special. I kind of wondering if there's anything that you're into. MICHAEL: I have some very basics. One, I don't know if I drink a lot or drink a little. I think the science on this is very confusing, kind of like drinking coffee. I try to drink less. I basically go back to the basics of I want cheap wine that's not terrible. That's what I'm always trying to discover. I think I've also started to rediscover just straight vodka. That's pretty good. I think that fits into the grand scheme. CHARLES: I just can't do it. I can't follow you there. I need some, what do they call them? Gin florals? I can drink gin -- MICHAEL: Oh yeah, that's good too. CHARLES: That's about as close as I can get to straight vodka. MICHAEL: And then food-wise, I just wrapped up finally figuring out how to cook fish and chicken without it tasting terrible. CHARLES: Oh! What's the secret? MICHAEL: No, I want to put a disclaimer out. There's a EULA on this. I'm not responsible for anything bad that happens but what you want to do is cook at about 10 degrees less than you're supposed to. A chicken is supposed to be 165 degrees but you take it out of the pot when it's like 150 or 155 on another part of the pan. Fish is supposed to be 145 degrees but you take it off when it's about 130 or 135. It cooks a little bit more but these guidelines to cook your meat to that thing, it ruins it. Also you can brine a chicken and things like that. Also, what you want to get is an instant meat thermometer. One of those that you can just poke in your meat so you're always checking the temperature. That's what I've been working on. CHARLES: I have a theory about that. I will laid out really quickly, maybe it's just because the juices. It's the juice that so yummy there so you want those to be locked in and boiling but not boiled away. I'm going to give that a try on my -- MICHAEL: And fish is particularly tricky. CHARLES: Because all it takes is five minutes. Sometimes, it's two minutes and 30 seconds too long and you ruin the fish. MICHAEL: Then the next theory I want to try out is that you can actually fry fish in pure butter but you've got to paper towel it off afterwards because too much butter ruins it. But I think if your paper tower it off like you do grease off of bacon, then I think that's how you achieve -- not as good as a restaurant because in a restaurant, they have those butane torches and the crisp it up on the outside or reverse sear or whatever -- CHARLES: Is that what they do? Do they just run their torch right over the fish? MICHAEL: That's all I can figure. They might also be professional cooks who know how to cook things. CHARLES: They might have done it a lot of times. They might have had someone like Gordon Ramsay yelling at them constantly. "I can't believe this fish is so terrible. Waah!" All right. I'm going to give the fish a try. I'm going to give the chicken a try and I'm going to give everything that you just spent the last hour talking about, also a try. MICHAEL: Well, thanks for having me on. It's always fun to have a show with you. I just posted yesterday our second revival of the Drunken Retired Podcast, which is over at Cote.show. It's just '.show'. URLs are crazy nowadays. I guess the only self-promotional thing I have is I'm over in Twitter @Cote. It'd be nice if everyone should just go follow me there because I'm always very sad that I don't have enough followers and they'll never verify me. I don't understand what the problem is. I'm clearly me. Then I mentioned earlier, the main podcast that I do is Software Defined Talk, which is at SoftwareDefinedTalk.com and you should come spend a lot of money on Pivotal stuff. I'm happy to tell you all about that. Just go check out Pivotal at Pivotal.io CHARLES: I guess that is about it. We will talk to everybody later. Thank you for staying tuned and listening to this supersized episode. Come check us out sometime!
© 2020-2025 Ivy Podcast Discovery LLC
