Podcasts about Linden Lab

In this special year-end episode of OpenObservability Talks, we are thrilled to host Charity Majors, co-founder and CTO of Honeycomb, for an insightful conversation on the state of observability. Charity and our host Horovits recently delivered keynotes at Open Source Observability Day, which sparked fascinating discussions on the evolution of open observability and its impact on the broader industry. Together, they run a 2024 yearly postmortem on the key insights and trends, exploring what the observability community and industry have accomplished this year. Looking ahead, they also discuss what's on the horizon for observability in 2025 and beyond. Charity Majors pioneered the concept of modern Observability, drawing on her years of experience building and managing massive distributed systems at Parse (acquired by Facebook), Facebook, and Linden Lab building Second Life. She is the co-author of Observability Engineering and Database Reliability Engineering (O'Reilly).  Join us for this fireside chat as we wrap up the year with the influential voices in observability. The episode was live-streamed on 9 December 2024 and the video is available at https://www.youtube.com/watch?v=D7ssNKAmYMs You can read the recap post at https://medium.com/p/94f80fff77e8/ OpenObservability Talks episodes are released monthly, on the last Thursday of each month and are available for listening on your favorite podcast app and on YouTube. We live-stream the episodes on Twitch and YouTube Live - tune in to see us live, and chime in with your comments and questions on the live chat. ⁠⁠https://www.youtube.com/@openobservabilitytalks⁠   https://www.twitch.tv/openobservability⁠ Show Notes: 00:00 - intro 01:51 - major observability trends of 2024 05:14 - OpenTelemetry trends 07:50 - Observability 2.0 14:45 - AI for DevOps and Observability 27:02 - Platform engineering 36:37 - observability query and data analytics 43:40 - observability for business insights 46:53 - how to start observability in Greenfield projects 50:15 - additional use cases for observability 54:11 - controlling cost of observability 58:47 - outro Resources: Practitioner's guide to wide events: https://jeremymorrell.dev/blog/a-practitioners-guide-to-wide-events/ Charity Major's blog on Observability 2.0: https://www.honeycomb.io/blog/time-to-version-observability-signs-point-to-yes Observability Is A Data Analytics Problem: https://insideainews.com/2022/04/07/observability-is-a-data-analytics-problem/ Platform as a Product survey by the CNCF: https://www.linkedin.com/feed/update/urn:li:share:7267977952242397185/ SaaS observability: https://medium.com/p/b2db276305b2 Expensive Metrics: Why Your Monitoring Data and Bill Get Out Of Hand: https://medium.com/p/e5724619e3f1 Sampling best practices: https://logz.io/learn/sampling-in-distributed-tracing-guide/ Socials: Twitter:⁠ https://twitter.com/OpenObserv⁠ YouTube: ⁠https://www.youtube.com/@openobservabilitytalks⁠ Dotan Horovits ============ Twitter: @horovits LinkedIn: www.linkedin.com/in/horovits Mastodon: @horovits@fosstodon BlueSky: @horovits.bsky.social Charity Majors ============ Twitter: https://x.com/mipsytipsy LinkedIn: https://www.linkedin.com/in/charity-majors Mastodon: @mipsytipsy@hachyderm.io BlueSky: https://bsky.app/profile/mipsytipsy.bsky.social

Follow me @samirkaji for my thoughts on the venture market, with a focus on the continued evolution of the VC landscape.Today I'm excited to speak with the founding team of Chemistry, a new venture firm led by Kristina Shen, Ethan Kurzweil, and Mark Goldberg, who recently spun-out of blue chip firms Andreessen Horowitz, Bessemer, and Index Ventures, respectively. The firm just announced a significantly oversubscribed $350MM debut fund. As a new entrant to the market (in the toughest time to start a new firm in over a decade), I wanted to ask them about their blueprint for building a firm, including how they chose to partner up and the work they did beforehand, LP strategies and selection, and what they felt was their unique reason to exist in a highly competitive market. About Kristina ShenKristina Shen is Co-Founder and Managing Partner at Chemistry Ventures, overseeing a $350M fund focused on early-stage software investments. Formerly a General Partner at Andreessen Horowitz (2019-2024), she led significant investments in Mux, Pave, Wrapbook, and Rutter. Kristina specialized in high-growth startups.She began her venture career as a Partner at Bessemer Venture Partners (2013-2019), working with companies such as Gainsight, Instructure, and ServiceTitan. Previously, she worked in investment banking at Goldman Sachs and Credit Suisse, focusing on technology sectors.About Mark GoldbergMark Goldberg is Co-Founder and Managing Partner at Chemistry Ventures since, investing in seed and Series A software startups. Previously, a Partner at Index Ventures (2015-2023), he worked with companies such as Plaid, Pilot, Intercom, and Motive, establishing a strong fintech and software portfolio.Prior to Index, Mark worked at Dropbox in Business Strategy & Operations and Strategic Finance (2013-2015), where he contributed to growth strategies during Dropbox's scaling phase.He started his career as an Analyst at Morgan Stanley (2007-2010) before joining Hudson Clean Energy as a Senior Associate. Mark holds an AB in International Relations from Brown University.About Ethan KurzweilEthan Kurzweil is Co-Founder and Managing Partner at Chemistry Ventures, leading investments at the seed stage for tech-driven startups. He also serves as a board member for companies like Intercom and LaunchDarkly.Previously, Ethan was a Partner at Bessemer Venture Partners (2008-2024), where he worked with companies such as HashiCorp, Twilio, and Twitch. His focus on software and digital platforms spanned roles as board member and investor, contributing to significant IPOs and acquisitions.Early in his career, Ethan worked in business development at Linden Lab (creators of Second Life) and served as a Senior Manager in the CEO's Office at Dow Jones. He holds an MBA from Harvard Business School and an AB in Economics from Stanford University.In this episode, we discuss:* (01:43): Importance of Team Chemistry and Partnership Formation* (03:27): Challenges of Building a Firm in the Current Environment* (08:00): Unique Value Proposition for Early-Stage Founders* (10:18): Early-Stage Focus and Differentiation from Large VC Firms* (16:12): Fundraising Insights and LP Relationship Building* (19:00): Choosing Aligned LPs and Targeting Long-Term Partnerships* (27:23): Single-Trigger Investment Decision-Making Model* (30:12): Balancing Conviction with Collaborative Feedback* (35:23): Independent Decision-Making for Follow-On Investments* (39:19): Personal Contrarian Beliefs about the Venture Industry* (42:18): Closing Remarks on Building a New Venture FranchiseI'd love to know what you took away from this conversation with Kristina, Mark, and Ethan. Follow me @SamirKaji and give me your insights and questions with the hashtag #ventureunlocked. If you'd like to be considered as a guest or have someone you'd like to hear from (GP or LP), drop me a direct message on Twitter.Podcast Production support provided by Agent Bee This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit ventureunlocked.substack.com

Charity Majors is the co-founder and CTO of honeycomb.io. She pioneered the concept of modern Observability, drawing on her years of experience building and managing massive distributed systems at Parse (acquired by Facebook), then subsequently at Facebook, and at  Linden Lab building Second Life. She is the co-author of Observability Engineering and Database Reliability Engineering (O'Reilly). She loves free speech, free software and single malt scotch.    Do you have something cool to share? Some questions? Let us know: - web: kubernetespodcast.com - mail: kubernetespodcast@google.com - twitter: @kubernetespod   News of the week CNCF Blog: Vitess 20 is now Generally Available Vitess Blog: Announcing Vitess 20 Anthropic Blog: Claude 3.5 Sonnet KubeCon India 2024 CFP Apps on Azure Blog: Announcing support of OCI v1.1 specification in Azure Container Registry VMware Tanzu Blog: Announcing VMware Tanzu Greenplum 7.2: Powering Your Business with Enhanced Performance and Advanced Capabilities VMware Tanzu Blog: Join the public beta for GenAI on Tanzu Platform today! CNCF: Adobe End User Journey Report Links from the interview Honeycomb.io O'Reilly Book: Observability Engineering O'Reilly Book: Database Reliability Engineering Charity's blog site: charity.wtf Charity Blog: Questionable Advice: “My boss says we don't need any engineering managers. Is he right?” Daniel H. Pink book: “Drive: The Surprising Truth About What Motivates Us” In which, “He examines the three elements of true motivation—autonomy, mastery, and purpose-and offers smart and surprising techniques for putting these into action in a unique book that will change how we think and transform how we live.” Charity blog on Stack Overflow: “Generative AI is not going to build your engineering team for you” In which she talks about how the tech industry is an apprenticeship industry. Charity Majors in the Google Cloud Next 2024 Developer Keynote honeycomb.io blog: “How Time Series Databases Work—And Where They Don't” by Alex Vondrak honeycomb.io blog: “Why Observability Requires a Distributed Column Store” by Alex Vondrak Links from the post-interview chat CNCF Kubernetes Community Days (KCDs) CNCF Kubernetes Community Days (KCDs) on GitHub Julia Evans Blog Wizard Zines by Julia Evans “Help! I Have a Manager!” zine by Julia Evans Aja Hammerly aka “thagomizer” blog “The Toaster Parable” “Manager Toolkit: Manage The Person In Front Of You” “Manager Toolkit: Useful Manager Phrases for 1:1s” “Manager Toolkit: You Talk, I Type”  

In this episode of the Steering Engineering Podcast, we explore how emerging AI technologies, such as AI code assistants, are reshaping the landscape of software design and development. Our focus is on how engineers are transitioning from hands-on coding to roles that more closely resemble that of an engineering manager. We examine the implications of generative AI for software engineering education, on-the-job training, roles/responsibilities, and career development.Charity Majors is an operations and database engineer, “sometimes” engineering manager, author and CTO at Honeycomb. Charity was a production engineering manager at Facebook and spent several years working on Parse. She also spent several years at Linden Lab, working on the infrastructure and databases that power Second Life. Charity is the co-author of O'Reilly's Database Reliability Engineering and author of "Observability Engineering: Achieving Production Excellence.” She loves free speech, free software, and single malt scotch.

Welcome back to the podcast! In today's must-listen episode, Chantel got to speak with Jordan Moradian   Jordan Moradian is an experienced professional who currently holds the position of Head of Growth at SiPhox Health. Prior to this role, Jordan was the Co-Founder and CEO of Crawl Technologies Inc. Jordan has also worked as a Software Development Engineer at Amazon Web Services (AWS), specifically in the AWS AI | Rekognition department. With a background in data science and robotics, Jordan has interned at companies like Linden Lab, Tufts Human Robot Interaction Lab, Walleye Trading Advisors, and MD Biosciences. Jordan graduated from Tufts University in 2019.   Enjoy!   Heart and Soil: Website: http://chantelrayway.com/liver  Use Coupon Code: chantelray   Today's Episode Is Sponsored By BiOptimizers Masszymes: http://masszymes.com/waistawayfree    Use code waistaway10 for a special discount!   Today's Episode Is Sponsored By BiOptimizers Magnesium Breakthrough: Visit https://magbreakthrough.com/waistaway and enter code waistaway for 10% off any order. https://magbreakthrough.com/rf_special?rfsn=7678975.73fd57&utm_source=refersion&utm_medium=affiliate&utm_campaign=7678975.73fd57     Masszymes - https://bioptimizers.com/shop/products/masszymes?rfsn=7678975.73fd57&utm_source=refersion&utm_medium=affiliate&utm_campaign=7678975.73fd57   HCL (Hydrochloric Acid) - https://bioptimizers.com/shop/products/hcl-breakthrough?rfsn=7678975.73fd57&utm_source=refersion&utm_medium=affiliate&utm_campaign=7678975.73fd57     Sleep Breakthrough - https://bioptimizers.com/shop/products/sleep-breakthrough?rfsn=7678975.73fd57&utm_source=refersion&utm_medium=affiliate&utm_campaign=7678975.73fd57    Join Our Non-Toxic Family MasterClass: Website: https://nontoxicfamily.com/masterclass/ Join Our Facebook Group: https://www.facebook.com/groups/TheChantelRayWay/   Order One Meal And A Tasting: https://chantelrayway.com/onemeal/    Order All The Books: Waist Away: The Chantel Ray Way - 2nd Edition:  https://www.amazon.com/gp/product/0999823116/ref=dbs_a_def_rwt_hsch_vapi_tpbk_p1_i0    Fasting to Freedom: The Gift of Fasting: https://www.amazon.com/Fasting-Freedom-Gift-Chantel-Ray/dp/0999823132/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=&sr=    Freedom From Food: A Six Week Bible Study Course: https://www.amazon.com/Freedom-Food-Bible-Study-Course/dp/0999823159/ref=pd_bxgy_img_3/135-7722513-4171815?_encoding=UTF8&pd_rd_i=0999823159&pd_rd_r=91d59435-2126-4f9d-867e-00646964e3e4&pd_rd_w=mg3U0&pd_rd_wg=FcVwL&pf_rd_p=fd3ebcd0-c1a2-44cf-aba2-bbf4810b3732&pf_rd_r=NWM3687GJSRKKQ4BYQP4&psc=1&refRID=NWM3687GJSRKKQ4BYQP4    Connect With Us:   Leave us a review: https://chantelrayway.com/review/    Share YOUR Story: https://chantelrayway.com/contact/   Contact directly through email at questions@chantelrayway.com    Enjoy refreshing, all-natural wine: https://chantelrayway.com/wine/   Listen to the new audiobook as a podcast HERE: https://chantelrayway.com/purchase-audio-book/   Free Video Preview: https://chantelrayway.com/top-12-thin-eater-tips-free-video/   Check out the VIDEO COURSE here: https://chantelrayway.com/video-course/   Purchase on Amazon Here: https://www.amazon.com/shop/intermittentfastingthechantelrayway   Strengthen your immune system with Vitamin C: https://chantelrayway.com/vitaminc/    Enjoy a FREE smoothie recipe book: https://chantelrayway.com/freerecipe/   Re-energize with nutritious algae Energybits: https://chantelrayway.com/energybits    Castor Oil: https://chantelrayway.com/castoroil   Connect with us on Social Media:   YouTube Channel Link: https://www.youtube.com/channel/UCteFjiVaY6n0SOAixcyZbWA   Like us on Facebook at https://www.facebook.com/TheChantelRayWay       Things we love: https://chantelrayway.com/things-i-love-2/   Facebook group: https://www.facebook.com/groups/TheChantelRayWay   ***As always, this podcast is not designed to diagnose, treat, prevent or cure any condition and is for information purposes only. Please consult with your healthcare professional before making any changes to your current lifestyle.***

This week on Screaming in the Cloud, Corey is joined by good friend and colleague, Charity Majors. Charity is the CTO and Co-founder of Honeycomb.io, the widely popular observability platform. Corey and Charity discuss the ins and outs of observability 1.0 vs. 2.0, why you should never underestimate the power of software to get worse over time, and the hidden costs of observability that could be plaguing your monthly bill right now. The pair also shares secrets on why speeches get better the more you give them and the basic role they hope AI plays in the future of computing. Check it out!Show Highlights:(00:00 - Reuniting with Charity Majors: A Warm Welcome(03:47) - Navigating the Observability Landscape: From 1.0 to 2.0(04:19) - The Evolution of Observability and Its Impact(05:46) - The Technical and Cultural Shift to Observability 2.0(10:34) - The Log Dilemma: Balancing Cost and Utility(15:21) - The Cost Crisis in Observability(22:39) - The Future of Observability and AI's Role(26:41) - The Challenge of Modern Observability Tools(29:05) - Simplifying Observability for the Modern Developer(30:42) - Final Thoughts and Where to Find MoreAbout CharityCharity is an ops engineer and accidental startup founder at honeycomb.io. Before this she worked at Parse, Facebook, and Linden Lab on infrastructure and developer tools, and always seemed to wind up running the databases. She is the co-author of O'Reilly's Database Reliability Engineering, and loves free speech, free software, and single malt scotch.Links:https://charity.wtf/Honeycomb Blog: https://www.honeycomb.io/blogTwitter: @mipsytipsy

How can you gain deeper insights into your complex systems beyond just monitoring infrastructure health metrics? Join us as Charity Majors, CTO and Co-Founder of Honeycomb, challenges traditional approaches to observability. With experience from the infrastructure trenches of fast-growing startups, Charity pushes us to rethink our methods.Can high-cardinality data exploration reveal the "unknown unknowns" hiding in your telemetry? Is prioritizing user experiences over infrastructure stats the key to untangling your "hairball" systems? And what role should observability play across the full software development lifecycle? Charity offers a forward-looking perspective on evolving observability practices to match increasing complexity. Observe the future of observability - Tune in to our latest episode now!‍Charity Majors is a Co-Founder and Engineer at Honeycomb.io, a startup that blends the speed of time series with the raw power of rich events to give you interactive, iterative debugging of complex systems. She has worked at companies like Facebook, Parse, and Linden Lab, as a systems engineer and engineering manager, but always seems to end up responsible for the databases too. She loves free speech, free software and a nice peaty single malt.Sponsored by: https://www.env0.com/

Es war einmal vor langer Zeit, in einer Welt, da war das Computer-Programm "Second Life" eine ziemlich große Sache. Wir reisen in dieser Folge der "Neurotainment Show" zurück in diese Zeit - und bereiten uns dadurch vielleicht auch für die Zukunft vor, wenn fortschrittlichere virtuelle Realitäten Gestalt annehmen werden.Second Life heute: https://secondlife.com/Mehr Neurotainment: https://www.simon.vision/

RAJ'S BIO Raj Date is one of the most prolific and multi-lensed people in finance. He also happens to be an incredible human being, a dear friend and business partner. He is Managing Partner of Fenway Summer, an advisory and investment firm focused on financial services and financial technology. He chairs the investment committee of Fenway Summer Ventures and is a general partner of Crossbeam Venture Partners, both venture capital funds. He also serves on the boards of Circle, a digital asset firm; Green Dot, a technology-driven mass market bank; Linden Lab, an internet company best known as the creator of Second Life, and the metaverse payments pioneer Tilia. He is founding director of the Payments Leadership Council, a CEO-led trade association. For Raj, Fenway is the latest chapter in a long and varied career in and around U.S. financial institutions — as a senior policymaker, as a bank executive, and a deal maker on Wall Street. He was the first-ever Deputy Director of the U.S. Consumer Financial Protection Bureau (CFPB). As the Bureau's second-ranking official, he helped launch the agency and steward its strategy, its operations, and its policy agenda. He also served on the senior staff committee of the Financial Stability Oversight Council, and as a statutory deputy to the FDIC Board. Before his public service, Raj was a Managing Director in the Financial Institutions Group at Deutsche Bank Securities, Senior Vice President for Corporate Strategy and Development at Capital One Financial, and a strategy consultant in the financial institutions practice of McKinsey & Company. Raj is a graduate of the College of Engineering at the University of California at Berkeley (highest honors) and the Harvard Law School (magna cum laude). RAJ RELATED LINKS Wikipedia Profile Fenway Summer Circle | Green Dot | Linden Lab American Banker Profile Testimony | CFPB 1st 100 Days Orrick's RegFi Podcast Episode GENERAL INFO| TOP OF THE GAME: Official website: https://topofthegame-thepod.com/ RSS Feed: https://feed.podbean.com/topofthegame-thepod/feed.xml Hosting service show website: https://topofthegame-thepod.podbean.com/ Javier's LinkTree: https://linktr.ee/javiersaade & Bio: https://tinyurl.com/36ufz6cs  SUPPORT & CONNECT: LinkedIn: https://www.linkedin.com/showcase/96934564 Facebook: https://www.facebook.com/profile.php?id=61551086203755 Twitter: https://twitter.com/TOPOFGAMEpod Subscribe on Podbean: https://www.podbean.com/site/podcatcher/index/blog/vLKLE1SKjf6G Email us: info@topofthegame-thepod.com   THANK YOU FOR LISTENING – AVAILABLE ON ALL MAJOR PLATFORMS  

Charity Majors is Co-Founder and CTO of Honeycomb, which provides full-stack observability that enables engineers to deeply understand and debug production software together. Victoria and Will talk to Charity about observability, her technical background and decision to start Honeycomb.io, thoughts about the whole ops SRE profession, and things that surprised her along her journey of building a company around observability as a concept. Honeycomb (https://www.honeycomb.io/) Follow Honeycomb on Facebook (https://www.facebook.com/honeycombio), Twitter (https://twitter.com/honeycombio), Youtube (https://www.youtube.com/channel/UCty8KGQ3oAP0MQQmLIv7k0Q), or LinkedIn (https://www.linkedin.com/company/honeycomb.io/). Follow Charity Majors on LinkedIn (https://www.linkedin.com/in/charity-majors/) or Twitter (https://twitter.com/mipsytipsy), or visit her website (https://charity.wtf/). Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your other host, Will Larry. And with us today is Charity Majors, Co-Founder and CTO of Honeycomb, which provides full-stack observability that enables engineers to deeply understand and debug production software together. Charity, thank you for joining us. How are you doing? CHARITY: Thanks for having me. I'm a little bit crunchy from a [laughs] long flight this morning. But I'm very happy to be home in San Francisco and happy to be talking to you. VICTORIA: Wonderful. And, Charity, I looked at your profile and noticed that you're a fan of whiskey. And I thought I might ask you just to get us started here, like, what's your favorite brand? CHARITY: Oh, goodness, that's like asking me to choose my favorite child if I had children. [laughter]. You know, I used to really be into the peaty scotches, the Islays, in particular. But lately, I've been more of a bourbon kick. Of course, everybody loves Pappy Van Winkle, George T. Stagg; impossible to find now, but it's so, so good. You know, if it's high-proof and single barrel, I will probably drink it. VICTORIA: That sounds great. Yeah, I tend to have the same approach. And, like, people ask me if I like it, and I like all of them. [laughter] I don't [inaudible 01:21] that I didn't like. [laughs] CHARITY: [inaudible 01:23] tongue sting? Then I'm in. [laughs] VICTORIA: Yeah, [inaudible 01:26]. WILL: See, I'm the opposite. I want something smooth. I'm a fruity drink type of guy. I'm just going, to be honest. CHARITY: There's no shame in that. WILL: No shame here. [laughs] Give me a margarita, and you have a happy Will for life. [laughs] VICTORIA: We'll have to get you to come out and visit San Diego for some margaritas, Will. That's -- CHARITY: Oh yeah. VICTORIA: Yeah, it's the place to be. Yeah, we do more of a bourbon drink in our house, like bourbon soda. That's usually what we make, like, my own custom simple syrup, and mix it with a little bourbon and soda water. And that's what we do for a cool down at the end of the day sometimes, yeah. Well, awesome. Let's see. So, Charity, why don't you just tell me a little more about Honeycomb? What is it? CHARITY: Well, it's a startup that hasn't failed yet, so... [laughs] to my own shock. [laughs] We're still around seven and a half years in. And I say that just so much joking. Like, you're not really supposed to say this as a founder, but, like, I 100% thought we were going to fail from the beginning. But we haven't yet, and we just got more money. So we'll be around for a while. We kind of pioneered the whole concept of observability, which now doesn't really mean anything at all. Everybody and their mother is like, well, I do observability, too. But back when we started talking about it, it was kind of a little bit revolutionary, I guess in that, you know, we started talking about how important it is to have high cardinality data in your systems. You really can't debug without it. And the fact that our systems are getting just astronomically more complex, and yet, we're still trying to debug it with these tools based on, you know, the metric data type [laughs] defined since the '70s when space was incredibly rare and expensive. And now space is incredibly cheap, but we should be wasteful with it so we can understand our incredibly complex systems. So that's us. We really try to empower software engineers to own their own code in production. For a long time, it was like, all of the tools for you to understand your software were really written for low-level ops people because they speak the language of, like, RAM, and disks, and CPU, which you shouldn't have to understand that in order to be able to understand I just deployed something, what went wrong? WILL: I love the honesty because there are so many founders that I'll talk to, and I'm like, okay, you're very successful. But did you really expect this to be what it is today? Did you really expect to survive? Because, like, just some of their ideas, I'm like, it's brilliant, but if I was with you back in the day, I'd be like, it ain't going to work. It's not going to work. [laughs] CHARITY: Yeah. And I feel like the VC culture really encourages delusion, just, like, self-delusion, like, this delusive thinking. You're supposed to, like, broadcast just, like, rock-solid confidence in yourself and your ideas at all time. And I think that only sociopaths do that. [laughs] I don't want to work for anyone who's that confident in themselves or their idea. Because I'm showing my own stripes, I guess, you know, I'm a reliability engineer. I wake up in the morning; I'm like, what's wrong with the day? That's just how my brain works. But I feel like I would rather work with people who are constantly scanning the horizon and being like, okay, what's likely to kill us today? Instead of people who are just like, I am right. [laughs] You know? VICTORIA: Yeah. And I can relate that back to observability by thinking how, you know, you can have an idea about how your system is supposed to work, and then there's the way that it actually works. [laughs] CHARITY: Oh my God. VICTORIA: Right? CHARITY: Yes. It's so much that. VICTORIA: Maybe you can tell us just a little bit more about, like, what is observability? Or how would you explain that to someone who isn't necessarily in it every day? CHARITY: I would explain it; I mean, it depends on who your audience is, of course. But I would explain it like engineers spend all day in their IDEs. And they come to believe that that's what software is. But software is not lines of code. Software is those lines of code running in production with real users using it. That's when software becomes real. And, for too long, we've treated like that, like, an entirely different...well, it's written. [laughs] You know, for launch, I was like, well, it's ops' problem, as the meme says. But we haven't really gotten to a point yet where...I feel like when you're developing with observability; you should be instrumenting your code as you go with an eye towards your future self. How am I going to know if this is working or not? How am I going to know if this breaks? And when you deploy it, you should then go and look at your code in production and look at it through the lens of the telemetry that you just wrote and ask yourself, is it doing what I expected it to? Does anything else look weird? Because the cost of finding and fixing bugs goes up exponentially from the moment that you write them. It's like you type a bug; you backspace. Cool, good for you. That's the fastest you can fix it. The next fastest is if you find it when you're running tests. But tests are only ever going to find the things you could predict were going to fail or that have already failed. The first real opportunity that you have to see if your code really works or not is right after you've deployed it, but only if you've given yourself the telemetry to do so. Like, the idea of just merging your code, like walking out the door or merging your code and waiting to get paged or to get [laughs] escalated to this is madness. This should be such an artifact of the battle days when dev writes, and ops runs it. That doesn't work, right? Like, in the beginning, we had software engineers who wrote code and ran that code in production, and that's how things should be. You should be writing code and running code in production. And the reason I think we're starting to see that reality emerge again is because our systems have gotten so complicated. We kind of can't not because you can't really run your code as a black box anymore. You can't ignore what's on the inside. You have to be able to look at the code in order to be able to run it effectively. And conversely, I don't think you could develop good code unless you're constantly exposing yourself to the consequences of that code. It lets you know when it breaks, that whole feedback loop that completely severed when we had dev versus ops. And we're slowly kind of knitting it together again. But, like, that's what's at the heart of that incredibly powerful feedback loop. It's the heart of all software engineering is, instrumenting your code and looking at it and asking yourself, is it doing what I expected it to do? WILL: That's really neat. You said you're a reliability engineer. What's your background? Tell me more about it because you're the CTO of Honeycomb. So you have some technical background. What does that look like? CHARITY: Yeah, well, I was a music major and then a serial dropout. I've never graduated from anything, ever. And then, I worked at startups in Silicon Valley. Nothing you'd ever...well, I worked at Linden Lab for a few years and some other places. But honestly, the reason I started Honeycomb was because...so I worked at Parse. I was the infrastructure lead at Parse; rest in peace. It got acquired by Facebook. And when I was leaving Facebook, it was the only time in my life that I'd ever had a pedigree. Well, I've actually been an ops engineer my entire career. When I was leaving Facebook, I had VCs going, "Would you like some money to do something? Because you're coming from Facebook, so you must be smart." On the one hand, that was kind of offensive. And on the other hand, like, I kind of felt the obligation to just take the money and run, like, on behalf of all dropouts, of women, and queers everywhere. Just, you know, how often...am I ever going to get this chance again? No, I'm not. So, good. VICTORIA: Yes, I will accept your money. [laughs] CHARITY: Yeah, right? VICTORIA: I will take it. And I'm not surprised that you were a music major. I've met many, I would say, people who are active in social media about DevOps, and then it turns out they were a theater major, [laughs] or music, or something different. And they kind of naturally found their way. CHARITY: The whole ops SRE profession has historically been a real magnet for weirdo people, weird past, people who took very non-traditional. So it's always been about tinkering, just understanding systems. And there hasn't been this high bar for formal, you know, knowledge that you need just to get your first job. I feel like this is all changing. And it makes me kind of...I understand why it's changing, and it also makes me kind of sad. VICTORIA: So I think you have a quote about, you know, working on infrastructure teams that everything comes back to databases. CHARITY: [laughs] VICTORIA: I wonder if you could expand on that. CHARITY: I've been an accidental DBA my entire career. I just always seemed to be the one left holding the bag. [laughs] We were playing musical chairs. I just feel like, you know, as you're moving up the stack, you can get more and more reckless. As you move down the stack, the closer you get to, like, bits on disk, the more conservative you have to be, the more blast radius your mistakes could have. Like, shit changes all the time in JavaScript land. In database land, we're still doing CRUD operators, like, since Stonebreaker did it in the '70s. We're still doing very fundamental stuff. I love it, though, because, I don't know, it's such a capsule of computers at large, which is just that people have no idea how much shit breaks. [laughs] Stuff breaks all the time. And the beauty of it is that we keep going. It's not that things don't break. You have no idea how much stuff is broken in your stack right now. But we find ways to resolve it after the fact. I just think that data is so fascinating because it has so much gravity. I don't know, I could keep going, but I feel like you get the point. I just think it's really fun. I think danger is fun, I think. It might not surprise you to learn that I, too, was diagnosed with ADHD in the past couple of years. I feel like this is another strand that most DevOps, SRE types have in common, which is just [laughs] highly motivated in a good way by panic. [laughs] WILL: I love that you said you love danger because I feel like that is right in your wheelhouse. Like, you have to love danger to be in that field because it's predictable. You're the one that's coming in and putting out the fires when everyone sometimes they're running for the window. Like you said, like, you got caught holding the bag. So that's really neat. This is a big question for me, especially for being an engineer, a dev, do you find that product and design teams understand and see the value in SRE? CHARITY: Oooh. These types of cultural questions are always so difficult for me to gauge whether or not my sample is representative of the larger population. Because, in my experience, you know, ops teams typically rule the roost, like, they get final say over everything. But I know that that's not typically true. Like, throughout the industry, like, ops teams kind of have a history of being kind of kicked around. I think that they do see the value because everybody can see when it breaks. But I think that they mostly see the value when it breaks. I think that it takes a rare, farsighted product team to be able to consent to giving, like, investments all along in the kinds of improvements that will pay off later on instead of just pouring all of the resources into fast fixes and features and feature, feature, feature. And then, of course, you know, you slowly grind to a halt as a team because you're just amassing surface area. You're not paying down your tech debt. And I think it's not always clear to product and design leaders how to make those investments in a way that actually benefits them instead of it just being a cost center. You know, it's just something that's always a break on them instead of actually enabling them to move faster. WILL: Yeah, yeah. And I can definitely see that being an engineer dev. I'm going to change it a little bit. And I'm going to ask, Victoria, since you're the managing director of that team, how do you feel about that question? Do you feel that's the same thing, or what's your observation of that? VICTORIA: I think Charity is, like, spot on because it does depend on the type of organization that you're working in, the hierarchy, and who gets priority over budget and things like that. And so the interesting thought for me coming from federal IT organizations into more commercial and startup organizations is that there is a little bit of a disconnect. And we started to ask our designers and developers like, "Well, have you thought much about, like, what happens when this fails?" [laughs] And especially -- CHARITY: Great question. VICTORIA: Yeah, like, when you're dealing with, like, healthcare startups or with bank startups and really thinking through all the ways it could go wrong. Is it a new pathway? Which I think is exciting for a lot of people. And I'm curious, too, Charity, like with Honeycomb, was there things that surprised you in your journey of discovery about, you know, building a company about observability and what people wanted out of this space? CHARITY: Oh my goodness. [laughs] Was anything not a surprise? I mean, [laughs] yeah, absolutely. You're a director of what team? VICTORIA: I'm a managing director of our Mission Control team. CHARITY: Oooh. VICTORIA: Which is our platform engineering, and DevOps, and SRE team. CHARITY: Now, does your platform engineering team have product managers? VICTORIA: I think it might be me. [laughs] CHARITY: Aha. VICTORIA: It might be me. And we have a team lead, and our CTO is actually our acting development director. So he's really leading the development of that project platform. CHARITY: When I was in New York the last couple of days, I just gave a talk at KubeCon about the Perils, Pitfalls, and Pratfalls of Platform Engineering, just talking about all of the ways that platform teams accidentally steer themselves into the ditch. One of the biggest mistakes that people make in that situation is not running the platform team like a product team, you know, having a sort of, like, if we build it, they will come sort of a mentality towards the platform that they're building internally for their engineers, and not doing the things like, you know, discovery or finding out like, am I really building, you know, the most important thing, you know, that people need right now? And it's like, I didn't learn those skills as an engineer. Like, in the infrastructure land, we didn't learn how to work with product people. We didn't learn how to work with designers. And I feel like the biggest piece of career advice that I give, you know, people like me now, is learn how to work with product and like a product org. I'm curious, like, what you're observing in your realm when it comes to this stuff. Like, how much like a product org do you work? VICTORIA: Oh, I agree 100%. So I've actually been interested in applying our platform project to the thoughtbot Incubator Program. [laughs] CHARITY: Mmm. VICTORIA: So they have this method for doing market strategy, and user interviews, and all of that...exactly what you're saying, like, run it like a product. So I want them to help me with it. [laughs] CHARITY: Nice. VICTORIA: Yes, because I am also a managing director, and so we're managing a team and building business. And we also have this product or this open-source project, really. It's not...we don't necessarily want to be prescriptive with how we, as thoughtbot, tell people how to build their platforms. So with every client, we do a deep dive to see how is their dev team actually working? What are the pain points? What are the things we can do based on, like, you know, this collection of tools and knowledge that we have on what's worked for past clients that makes the most sense for them? So, in that way, I think it is very customer-focused [laughs], right? And that's the motto we want to keep with. And I have been on other project teams where we just try to reproduce what worked for one client and to make that a product. And it doesn't always work [laughs] because of what you're saying. Like, you have to really...and especially, I think that just the diversity of the systems that we are building and have been built is kind of, like, breathtaking [laughs], you know. CHARITY: Yeah. [chuckles] VICTORIA: I'm sure you have some familiarity with that. CHARITY: [laughs] VICTORIA: But what did you really find in the market that worked for you right away, like, was, like, the problem that you were able to solve and start building within your business? CHARITY: We did everything all wrong. So I had had this experience at Facebook, which, you know, at Parse, you know, we had all these reliability issues because of the architecture. What we were building was just fundamentally...as soon as any customer got big, like, they would take up all the resources in this shared, you know, tenancy thing, and the whole platform would go down. And it was so frustrating. And we were working on a rewrite and everything. Like, it was professionally humiliating for me as a reliability engineer to have a platform this bad at reliability. And part of the issue was that you know, we had a million mobile apps, and it was a different app every time, different application...the iTunes Store, like, top five or something. And so the previous generation of tools and strategies like building dashboards and doing retros and being like, well, I'll make a dashboard so that I can find this problem next time immediately, like, just went out the window. Like, none of them would work because they were always about the last battle. And it was always something new. And at one point, we started getting some datasets into this tool at Facebook called Scuba. It was butt ugly. Like, it was aggressively hostile to users. But it let us do one thing really well, which was slice and dice high cardinality dimensions in near real-time. And having the ability to do that to, like, break down by user ID, which is not possible with, you know, I don't know how familiar -- I'll briefly describe high cardinality. So imagine you have a collection of 100 million users. And the highest possible cardinality would be a unique ID because, you know, social security number, very high cardinality. And something much lower cardinality would be like inches of height. And all of metrics and dashboards are oriented around low cardinality dimensions. If you have more than a couple hundred hosts, you can no longer tag your metrics with a host ID. It just falls apart. So being able to break down by, like, you know, one of a million app IDs. It took...the amount of time it took for us to identify and find these brand-new problems, it dropped like a rock, like, from hours of opening it. We never even solved a lot of the problems that we saw. We just recovered. We moved on [laughs] with our day, dropped from that to, like, seconds or minutes. Like, it wasn't even an engineering problem anymore. It was like a support problem, you know, you just go click, click, click, click, click, oh, there it is. Just follow the trail of breadcrumbs. That made such an impression on me. And when I was leaving, I was just like, I can't go back to not having something like this. I was so much less powerful as an engineer. It's just, like, it's unthinkable. So when we started Honeycomb, we were just, like, we went hands down, and we started building. We didn't want to write a database. We had to write a database because there was nothing out there that could do this. And we spent the first year or two not even really talking to customers. When we did talk to customers, I would tell our engineers to ignore their feedback [laughs] because they were all telling us they wanted better metrics. And we're like, no, we're not doing metrics. The first thing that we found we could kind of connect to real problems that people were looking for was that it was high cardinality. There were a few, not many; there were a few engineers out there Googling for high cardinality metrics. And those engineers found us and became our earliest customers because we were able to do breathtaking...from their perspective, they were like, we've been told this is impossible. We've been told that this can't be done. Things like Intercom was able to start tagging other requests with, like, app ID and customer ID. And immediately started noticing things like, oh, this database that we were just about to have to, like, spend six months sharding and extending, oh, it turns out 80% of the queries in flight to this database are all coming from one customer who is paying us $200 a month, so maybe we shouldn't [laughs] do that engineering labor. Maybe we should just, you know, throttle this guy who is only paying us 200 bucks a month. Or just all these things you can't actually see until you can use this very, very special tool. And then once you can see that... So, like, our first customers became rabid fans and vouched for us to investors, and this still blows people's minds to this day. It's an incredibly difficult thing to explain and describe to people, but once they see it on their own data, it clicks because everybody's run into this problem before, and it's really frustrating. VICTORIA: Yeah, that's super interesting and a great example to illustrate that point of just, like, not really knowing what's going on in your system. And, you know, you mentioned just, like, certainly at scale, that's when you really, really need to have [laughs] data and insight into your systems. CHARITY: Yeah. VICTORIA: But one question I get a lot is, like, at what scale do you actually need to start worrying about SRE? [laughs] Which -- CHARITY: SRE? VICTORIA: Yeah, I'll let you answer that. Yeah, site reliability or even things like...like, everything under that umbrella like observability, like, you know, putting in monitoring and tracing and all this stuff. Sometimes people are just like, well, when do I actually have to care? [laughs] CHARITY: I recognize this is, you know, coming from somebody who does this for a living, so, like, people can write it off all they want. But, like, the idea of developing without observability is just sad to me, like, from day one. This is not a tax. It's not something that slows you down or makes your lives worse. It's something that makes your lives better from day one. It helps you move more quickly, with more confidence. It helps you not make as many mistakes. It helps you... Like, most people are used to interacting with their systems, which are just like flaming hairballs under their bed. Nobody has ever understood these systems. They certainly don't understand them. And every day, they ship more code that they don't understand, create systems that they've never understood. And then an alarm goes off, and everybody just, like, braces for impact because they don't understand them. This is not the inevitable end state of computing. It doesn't have to be like this. You can have systems that are well-understood, that are tractable, that you could...it's just...it's so sad to me that people are like, oh God, when do I have to add telemetry? And I'm just like, how do you write software without telemetry? How do you have any confidence that the work you're doing is what you thought you were doing? You know, I just... And, of course, if you're waiting to tack it on later, of course, it's not going to be as useful because you're trying to add telemetry for stuff you were writing weeks, or months, or years ago. The time to add it is while you're writing it. No one is ever going to understand your software as well as you do the moment that you're writing it. That's when you know your original intent. You know what you're trying to do. You know why you're trying to do it. You know what you tried that didn't work. You know, ultimately, what the most valuable pieces of data are. Why wouldn't you leave little breadcrumbs for yourself so that future you can find them? You know, it's like...I just feel like this entire mental shift it can become just as much of a habit as like commenting your code or adding, you know, commenting in your pull request, you know. It becomes second nature, and reaching for it becomes second nature. You should have in your body a feeling of I'm not done until you've looked at your telemetry in production. That's the first moment that you can tell yourself, ah, yes, it probably does what I think it does, right? So, like, this question it makes me sad. It gets me a little worked up because I feel like it's such a symptom of people who I know what their jobs are like based on that question, and it's not as good as it could be. Their jobs are much sadder and more confusing than it could be if they had a slightly different approach to telemetry. That's the observability bit. But about SRE, very few ops engineers start companies, it seems, when I did, you know, I was one of three founding members. And the first thing I did was, of course, spin up an infrastructure and set up CI/CD and all this stuff. And I'm, like, feeling less useful than the others but, you know, doing my part. But that stuff that I spun up, we didn't have to hire an SRE for years, and when we did, it was pretty optional. And this is a system, you know, things trickle down, right? Doing things right from the beginning and having them be clear and well-understood, and efficient, we were able to do so much with so few people. You know, we were landing, you know, hundreds of thousand-dollar deals with people who thought we had hundreds of employees. We had 12 engineers for the first almost five years, just 12 engineers. But, like, almost all of the energy that they put into the world went into moving the business forward, not fighting with the system, or thrashing the system, or trying to figure out bugs, or trying to track down things that were just, like, impossible to figure out. We waste so much time as engineers by trying to add this stuff in later. So the actual answer to your question is, like, if you aren't lucky enough to have an ops co-founder, is as soon as you have real users. You know, I've made a career out of basically being the first engineer to join from infrastructure when the software engineers are starting to have real customers. Like, at Parse, they brought me in when they were about to do their alpha release. And they're like, whoa, okay, I guess we better have someone who knows how to run things. And I came in, and I spent the next, you know, year or so just cleaning up shit that they had done, which wasn't terrible. But, you know, they just didn't really know what they were doing. So I kind of had to undo everything, redo it. And just the earlier, the better, right? It will pay off. Now, that said, there is a real risk of over-engineering early. Companies they don't fail because they innovated too quickly; let's put it that way. They fail because they couldn't focus. They couldn't connect with their customers. They couldn't do all these things. And so you really do want to do just enough to get you to the next place so that you can put most of your effort into making product for your customers. But yeah, it's so much easier to set yourself up with auto-deployment so that every CI/CD run automatically deploys your code to production and just maintain as you grow. That is so easy compared to trying to take, you know, a long, slow, you know, leaky deploy process and turn it into one that could auto-deploy safely after every commit. So yeah, do it early. And then maintain is the easiest way in the world to do this stuff. Mid-Roll Ad: As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what's important to your customers to help you transition to intuitive digital services your customers will trust. We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. WILL: Correct me if I'm wrong, I think you said Facebook and mobile. Do you have, not experience with mobile but do you...does Honeycomb do anything in the mobile space? Because I feel like that portion is probably the most complicated for mobile, like, dealing with iOS and Android and everything that they're asking for. So... CHARITY: We don't have mobile stuff at Honeycomb. Parse was a mobile Backend as a Service. So I went straight from doing all mobile all the time to doing no mobile at all. I also went from doing databases all the time to doing, you know...it's good career advice typically to find a niche and then stay in it, and I have not followed that advice. [laughter] I've just jumped from...as soon as I'm good at something, I start doing something else. WILL: Let me ask you this, how come you don't see more mobile SRE or help in that area? CHARITY: I think that you see lots of SREs for mobile apps, but they're on the back-end side. They're on the server side. So it's just not as visible. But even if you've got, like, a stack that's entirely serverless, you still need SRE. But I think that the model is really shifting. You know, it used to be you hired an SRE team or an ops team to carry the pager for you and to take the alerts and to, like, buffer everything, and nowadays, that's not the expectation. That's not what good companies do. You know, they set up systems for their software engineers to own their code in production. But they need help because they're not experts in this, and that's where SRE types come in. Is that your experience? WILL: Yeah, for the most part. Yeah, that is. CHARITY: Yeah, I think that's very healthy. VICTORIA: And I agree with that as well. And I'm going to take that clip of your reaction to that question about when you should start doing [laughter] observability and just play for everybody whenever someone asks [laughs] me that. I'm like, here's the answer. That's great. CHARITY: I think a good metaphor for that is like, if you're buying a house and taking out a loan, the more of a down payment you can put down upfront, the lower that your monthly payments are going to be for the rest of your...you amortize that out over the next 20-30 years. The more you can do that, the better your life is going to be because interest rates are a bitch. VICTORIA: It makes sense. And yeah, like, to your point earlier about when people actually do start to care about it is usually after something has broken in a traumatic way that can be really bad for your clients and, like, your legal [laughter] stance -- CHARITY: That's true. VICTORIA: As a company. CHARITY: Facing stuff, yeah, is where people usually start to think about it. But, like, the less visible part, and I think almost the more important part is what it does to your velocity and your ability to execute internally. When you have a good, clean system that is well-tended that, you know, where the amount of time between when you're writing the code and when the code is in production, and you're looking at...when that is short and tight, like, no more than a couple of hours, like, it's a different job than if it takes you, like, days or weeks to deploy. Your changes get bashed up with other people's. And, you know, like, you enter, like, the software development death spiral where, you know, it takes a while. So your diffs get even bigger, so code review takes even longer, so it takes even longer. And then your changes are all getting bashed up. And, you know, now you need a team to run deploys and releases. And now you need an SRE team to do the firefighting. And, like, your systems are...the bigger it gets, the more complicated it gets, the more you're spending time just waiting on each other or switching contexts. You ever, like, see an app and been like, oh, that's a cool app? I wonder...they have 800 engineers at that company. And you're just like, what the hell are they all doing? Like, seriously, how does it take that many engineers to build this admittedly nice little product? I guarantee you it's because their internal hygiene is just terrible. It takes them too long to deploy things. They've forgotten what they've written by the time it's out, so nobody ever goes and looks at it. So it's just like, it's becoming a hairball under your bed. Nobody's looking at it. It's becoming more and more mysterious to you. Like, I have a rule of thumb which there's no mathematical science behind this, just experience. But it's a rule of thumb that says that if it takes you, you know, on the order of, say, a couple of hours tops to deploy your software, if it takes you that many engineers to build and own that product, well, if your deploys take on the order of days instead of hours, it will take you twice as many people [chuckles] to build and support that product. And if it takes you weeks to deploy that product, it will take you twice as many again; if anything, that is an underestimate because it actually goes up exponentially, not linearly. But, like, we are so wasteful when it comes to people's time. It is so much easier for managers to go, uh, we're overloaded. Let's hire more people. For some reason, you can always get headcount when you can't actually get the discipline to say no to things or the people to work on internal tools to, like, shrink that gap between when you've written it and when it's live. And just the waste, it just spirals out of control, man, and it's not good. And, you know, it should be such a fun, creative, fulfilling job where you spend your day solving puzzles for money and moving the business materially forward every day. And instead, how much of our time do we just sit here, like, twiddling our thumbs and waiting for the build to finish or waiting for code review [laughs] to get turned around? Or, you know, swapping projects and, like, trying to page all that context in your brain? Like, it's absurd, and this is not that hard of a problem to fix. VICTORIA: Engineering should be fun, and it should be dangerous. That's what [laughs] I'm getting out of this -- CHARITY: It should be fun, and it should be dangerous. I love that. VICTORIA: Fun and dangerous. I like it. [laughs] And speaking of danger, I mean, maybe it's not dangerous, but what does success really look like for you at Honeycomb in the next six months or even in the next five years? CHARITY: I find it much more easier to answer what failure would look like. VICTORIA: You can answer that too if you like. [laughs] CHARITY: [laughs] What would success look like? I mean, obviously, I have no desire to ever go through another acquisition, and I don't want to go out of business. So it'd be nice not to do either of those things, which means since we've taken VC money, IPO would be nice eventually. But, like, ultimately, like, what motivates Christine and me and our entire company really is just, you know, we're engineers. We've felt this pain. We have seen that the world can be better. [laughs] We really just want to help, you know, move engineering into the current decade. I feel like there are so many teams out there who hear me talk about this stuff. And they listen wistfully, and they're like, yeah, and they roll their eyes. They're like, yeah, you work in Silicon Valley, or yeah, but you work at a startup, or yeah...they have all these reasons why they don't get nice things. We're just not good enough engineers is the one that breaks my heart the most because it's not true. Like, it has nothing to do...it has almost nothing to do with how good of an engineer you are. You have to be so much better of an engineer to deal with a giant hairball than with software that gets deployed, you know, within the hour that you can just go look at and see if it's working or not. I want this to go mainstream. I want people...I want engineers to just have a better time at work. And I want people to succeed at what they're doing. And just...the more we can bring that kind of change to more and more people, the more successful I will feel. VICTORIA: I really like that. And I think it's great. And it also makes me think I find that people who work in the DevOps space have a certain type of mentality sometimes, [laughs] like, it's about the greater community and, like, just making being at work better. And I also think it maybe makes you more willing to admit your failures [laughs] like you were earlier, right? CHARITY: Probably. VICTORIA: That's part of the culture. It's like, well, we messed up. [laughs] We broke stuff, and we're going to learn from it. CHARITY: It's healthy. I'm trying to institute a rule where at all hands when we're doing different organizations giving an update every two weeks, where we talk two-thirds about our successes and things that worked great and one-third about things that just didn't work. Like, I think we could all stand to talk about our failures a lot more. VICTORIA: Yeah, makes it a lot less scary, I think [laughs], right? CHARITY: Yeah, yeah. It democratizes the feeling, and it genuinely...it makes me happy. It's like, that didn't work, great. Now we know not to do it. Of the infinite number of things that we could try, now we know something for real. I think it's exciting. And, I don't know, I think it's funny when things fail. And I think that if we can just laugh about it together... You know, in every engineering org that I've ever worked at, out of all the teams, the ops types teams have always been the ones that are the most tightly bonded. They have this real, like, Band of Brothers type of sentiment. And I think it's because, you know, we've historically endured most of the pain. [laughs] But, like, that sense of, like, it's us against the system, that there is hilarity in failure. And, at the end of the day, we're all just monkeys, like, poking at electrical sockets is, I think...I think it's healthy. [laughs] WILL: That's really neat. I love it. This is one of my favorite questions. What advice would you give yourself if you could go back in time? CHARITY: I don't know. I think I'd just give myself a thumbs up and go; it's going to be all right. I don't know; I wouldn't... I don't think that I would try to alter the time continuum [laughs] in any way. But I had a lot of anxiety when I was younger about going to hell and all this stuff. And so I think...but anything I said to my future self, I wouldn't have believed anyway. So yeah, I respectfully decline the offer. VICTORIA: That's fair. I mean, I think about that a lot too actually, like, I sometimes think like, well, if I could go back to myself a year ago and just -- CHARITY: Yeah. I would look at me like I was stupid. [laughter] VICTORIA: That makes sense. It reminds me a little bit about what you said, though, like, doing SRE and everything upfront or the observability pieces and building it correctly in a way you can deploy fastly is like a gift to your future self. [laughs] CHARITY: Yes, it is, with a bow. Yes, exactly. VICTORIA: There you go. Well, all right. I think we are about ready to wrap up. Is there anything you would like to promote specifically? CHARITY: We just launched this really cool little thing at Honeycomb. And you won't often hear me say the words cool and AI in proximity to each other, but we just launched this really dope little thing. It's a tool for using natural language to ask questions of your telemetry. So, if you just deployed something and you want to know, like, what's slow or did anything change, you can just ask it using English, and it does a ChatGPT thing and generates the right graphs for you. It's pretty sweet. VICTORIA: That's really cool. So, if you have Honeycomb set up and working in your system and then you can just ask the little chatbot, "Hey, what's going on here?" CHARITY: Yeah. What's the slowest endpoint? And it'll just tell you, which is great because I feel like I do not think graphically at all. My brain just really doesn't. So I have never been the person who's, like, creating dashboards or graphs. My friend Ben Hartshorne works with me, and he'll make the dashboards. And then I get up in the morning, and I bookmark them. And so we're sort of symbiotic. But everyone can tweak a query, right? Once you have something that you know is, like, within spitting distance as the data you want, anyone can tweak it, but composing is really hard. So I feel like this really helps you get over that initial hurdle of, like, er, what do I break down by? What do I group by? What are the field names? You just ask it the question, and then you've got to click, click, click, and, like, get exactly what you want out of it. I think it's, like, a game changer. VICTORIA: That sounds extremely cool. And we will certainly link to it in our show notes today. Thank you so much for being with us and spending the time, Charity. CHARITY: Yeah, this was really fun. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. WILL: And you could find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Charity Majors.

Follow me @samirkaji for my thoughts on the venture market, with a focus on the continued evolution of the VC landscape.On this week's show we're fortunate to be joined by Hunter Walk and Satya Patel, founders of Homebrew, a seed-stage firm founded over a decade ago that's backed companies such as Chime, AngelList, and Gusto. Just over a year ago, Homebrew announced that it was moving away from a seed-focused traditional LP-backed fund to an open-ended evergreen structure that is funded from the proceeds of prior investments.Additionally, they are also leading up efforts of Screendoor, a fund of funds focused on supporting underrepresented fund managers by offering capital and counsel. Satya is coming back on the show for the second time, and it was fun to have Hunter on with him this time, as we dove deep into their learnings from building homebrew, what they look for when back fund managers, and their view on what makes a great partner for founders. This was a fun one, and we think you'll really enjoy hearing their thoughts. Let's now get right into it!A word from our sponsor:Privately owned and headquartered in New York City, Grasshopper Bank is built to serve the business and innovation economy. As a client-first digital bank, Grasshopper combines the best of banking technology and years of industry expertise to deliver best-in-class experiences with trusted security and unparalleled support. Grasshopper's digital solutions are tailored for venture capital and private equity firms, startups and small businesses, fintech-focused Banking-as-a-Service (BaaS) and commercial API banking platforms, and more. Serving clients globally, Grasshopper provides flexible, firm-focused lending solutions, as well as a dedicated Relationship Manager committed to meeting the unique needs and strategic focus of your firm across all entities, including funds, general partner and management companies. Grasshopper is a member of the FDIC and an Equal Housing Lender.For more information, visit the bank's website at www.grasshopper.bank or follow on LinkedIn and Twitter.About Satya Patel:Satya Patel is a Founding Partner of Homebrew and Co-Founder of Screendoor. Prior to Homebrew, he was VP Product at Twitter, building and leading the Product Management and User Services teams. Before Twitter, he was a Partner at Battery Ventures, where he co-led the seed and early-stage investing practices. He joined Google in 2003 and was responsible for AdSense product management and partnerships.Before heading to Silicon Valley for Google, he worked for DoubleClick, in venture capital, and as a strategy consultant.He has a BS in Finance and a BS in Psychology from The University of Pennsylvania.About Hunter Walk:Hunter Walk is a Founding Partner of Homebrew and Co-Founder of Screendoor. Prior to Homebrew, Hunter led consumer product management at YouTube, starting when it was acquired by Google. He originally joined Google in 2003, managing product and sales efforts for AdSense, Google‘s contextual advertising business.His first job in Silicon Valley was as the founding product and marketing guy at Linden Lab.Before graduate school, he was a management consultant and also spent a year at Late Night with Conan O‘Brien. He has a BA in History from Vassar and MBA from Stanford University.In this episode we discuss:(03:32) The decision to move to an evergreen fund structure with Homebrew(07:32) The biggest constraints when early-stage fund sizes balloon(17:34) How to survive a down market and become a force multiplier on a cap table(24:58) The inspiration to start Screendoor(33:33) The type of managers they are looking to back at Screendoor(37:54) Patterns they've seen in great investors(42:13) The most important question they ask GPs(44:42) The biggest lessons from their time as investorsI'd love to know what you took away from this conversation with Satya and Hunter. Follow me @SamirKaji and give me your insights and questions with the hashtag #ventureunlocked. If you'd like to be considered as a guest or have someone you'd like to hear from (GP or LP), drop me a direct message on Twitter.Podcast Production support provided by Agent Bee This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit ventureunlocked.substack.com

Lex Neva, Staff Site Reliability Engineer at Honeycomb and Curator of SRE Weekly, joins Corey on Screaming in the Cloud to discuss reliability and the life of a newsletter curator. Lex shares some interesting insights on how he keeps his hobbies and side projects separate, as well as the intrusion that open-source projects can have on your time. Lex and Corey also discuss the phenomenon of newsletter curators being much more demanding of themselves than their audience typically is. Lex also shares his views on how far reliability has come, as well as how far we have to go, and the critical implications reliability has on our day-to-day lives. About LexLex Neva is interested in all things related to running large, massively multiuser online services.  He has years of SRE,  Systems Engineering, tinkering, and troubleshooting experience and perhaps loves incident response more than he ought to.  He's previously worked for Linden Lab, DeviantArt, Heroku, and Fastly, and currently works as an SRE at Honeycomb while also curating the SRE Weekly newsletter on the side.Lex lives in Massachusetts with his family including 3 adorable children, 3 ridiculous cats, and assorted other awesome humans and animals.  In his copious spare time he likes to garden, play tournament poker, tinker with machine embroidery, and mess around with Arduinos.Links Referenced: SRE Weekly: https://sreweekly.com/ Honeycomb: https://www.honeycomb.io/ 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: This episode is sponsored in part by our friends at Chronosphere. Tired of observability costs going up every year without getting additional value? Or being locked into a vendor due to proprietary data collection, querying, and visualization? Modern-day, containerized environments require a new kind of observability technology that accounts for the massive increase in scale and attendant cost of data. With Chronosphere, choose where and how your data is routed and stored, query it easily, and get better context and control. 100% open-source compatibility means that no matter what your setup is, they can help. Learn how Chronosphere provides complete and real-time insight into ECS, EKS, and your microservices, wherever they may be at snark.cloud/chronosphere that's snark.cloud/chronosphere.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Once upon a time, I decided to start writing an email newsletter, and well, many things happened afterwards, some of them quite quickly. But before that, I was reading a number of email newsletters in the space. One that I'd been reading for a year at the time, was called SRE Weekly. It still comes out. I still wind up reading it most weeks.And it's written by Lex Neva, who is not only my guest today but also a staff site reliability engineer at Honeycomb. Lex, it is so good to finally talk to you, other than reading emails that we send to the entire world that pass each other like ships in the night.Lex: Yeah. I feel like we should have had some kind of meeting before now. But yeah, it's really good to [laugh] finally meet you.Corey: It was one of the inspirations that I had. And to be clear, when I signed up for your newsletter originally—I was there for issue 15, which is many, many years ago—I was also running a small-scale SRE team at the time. It was, I found as useful as a part of doing my job and keeping abreast of what was going on in the ecosystem. And I found myself, once I went independent, wishing that your newsletter and a few others had a whole bunch more AWS content. Well, why doesn't it?And the answer is because you are, you know, a reasonable person who understands that mental health is important and boundaries exist for a reason. No one sensible is going to care that much about one cloud provider all the time [sigh]. If only we were all that wise.Lex: Right? Well, [laugh] well, first of all, I love your newsletter, and also the content that you write that—I mean, I would be nowhere without content to link to. And I'm glad you took on the AWS thing because, much like how I haven't written Security Weekly, I also didn't write any kind of AWS Weekly because there's just too much. So, thanks for falling on that sword.Corey: I fell on another one about two years ago and started the Thursdays, which are Last Week in AWS Security. But I took a different bent on it because there are a whole bunch of security newsletters that litter the landscape and most of them are very good—except for the ones that seem to be entirely too vendor-captured—but the problem is, is that they lacked both a significant cloud focus, as well as an understanding that there's a universe of people out here who care about security—or at least should—but don't have the word security baked into their job title. So, it was very insular, using acronyms they assume that everyone knows, or it's totally vendor-captured and it's trying to the whole fear, uncertainty, and doubt thing, “And that's why you should buy this widget.” “Will it solve problems?” “Well, it'll solve our revenue problems at our company that sells the widgets, but other than that, not really.” And it just became such an almost incestuous ecosystem. I wanted something different.Lex: Yeah. And the snark is also very useful [laugh] in order to show us that you're not in their pocket. So yeah, nice work.Corey: Well, I'll let you in on a secret, now that we are—what, I'm somewhat like 300 and change issues in, which means I've been doing this for far too long, the snark is a byproduct of what I needed to do to write it myself. Because let's face it, this stuff is incredibly boring. I needed to keep myself interested as I started down that path. And how can I continually keep it fresh and funny and interesting, but not go too far? That's a fun game, whereas copying and pasting some announcement was never fun.Lex: Yeah, that's not—I hear you on trying to make it interesting.Corey: One regret that I've had, and I'm curious if you've ever encountered this yourself because most people don't get to see any of this. They see the finished product that lands in their inbox every Monday, and—in my case, Monday; I forget the exact day that yours comes out. I collect them and read through them for them all at once—but I find that I have often had caused a look back and regret the implicit commitment in Last Week in AWS as a name because it would be nice to skip a week here and there, just because either I don't particularly feel like it, or wow, there was not a lot of news worth talking about that came out last week. But it feels like I've forced myself onto a very particular treadmill schedule.Lex: Yeah. Yeah, it comes with, like, calling it SRE Weekly. I just followed suit for some of the other weeklies. But yeah, that can be hard. And I do give myself permission to take a week off here and there, but you know, I'll let you in on a secret.What I do is I try to target eight to ten articles a week. And if I have more than that, I save some of them. And then when it comes time to put out an issue, I'll go look at what's in that ready queue and swap some of those in and swap some of the current ones out just so I keep things fresh. And then if I need a week off, I'll just fill it from that queue, you know, if it's got enough in it. So, that lets me take vacations and whatnot. Without that, I think I would have had a lot harder of a time sticking with this, or there just would have been more gaps. So yeah.Corey: You're fortunate in that you have what appears to be a single category of content when you construct your newsletter, whereas I have three that are distinct: AWS releases and announcements and news and things to make fun of for the past week; the things from the larger community folks who do not work there, but are talking about interesting approaches or news that is germane; and then ideally a tip or a tool of the week. And I found, at least lately, that I've been able to build out the tools portion of it significantly far in advance. Because a tool that makes working with AWS easier this week is probably still going to be fairly helpful a month from now.Lex: Yeah, that's fair. Definitely.Corey: But putting some of the news out late has been something of a challenge. I've also learned—by getting it wrong—that I'm holding myself to a tighter expectation of turnaround time than any part of the audience is. The Thursday news is all written the week before, almost a full week beforehand and no one complains about that. I have put out the newsletter a couple of times an hour or two after its usual 7:30 pacific time slot that it goes out in; not a single person has complained. In one case, I moved it by a day to accommodate an announcement but didn't explain why; not a single person emailed in. So, okay. That's good to know.Lex: Yeah, I've definitely gotten to, like, Monday morning, like, a couple of times. Not much, not many times, but a couple of times, I've gotten a Monday morning be like, “Oh, hey. I didn't do that thing yesterday.” And then I just release it in the morning. And I've never had a complaint.I've cancelled last minute because life interfered. The most I've ever had was somebody emailing me and be like, you know, “Hope you feel better soon,” like when I had Covid, and stuff like that. So, [laugh] yeah, sometimes maybe we do hold ourselves to a little bit of a higher standard than is necessary. I mean, there was a point where I got—I had major eye surgery and I had to take a month off of everything and took a month off the newsletter. And yeah, I didn't lose any subscribers. I didn't have any complaints. So people, I think, appreciate it when it's there. And, you know, if it's not there, just wait till it comes out.Corey: I think that there is an additional challenge that I started feeling as soon as I started picking up sponsors for it because it's well, but at this point, I have a contractual obligation to put things out. And again, life happens, but you also don't want to have to reach out on apology tours every third week or whatnot. And I think that's in part due to the fact that I have multiple sponsors per issue and that becomes a bit of a juggling dance logistically on this end.Lex: Yeah. When I started, I really didn't think I necessarily wanted to have sponsors because, you know, it's like, I have a job. This is just for fun. It got to the point where it's like, you know, I'll probably stop this if there's not some kind of monetary advantage [laugh]. And having a sponsor has been really helpful.But I have been really careful. Like, I have always had only a single sponsor because I don't want that many people to apologize to. And that meant I took in maybe less money than I then I could have, but that's okay. And I also was very clear, you know, even from the start having a contract that I may miss a week without notice. And yes, they're paying in advance, but it's not for a specific range of time, it's for a specific number of issues, whenever those come out. That definitely helped to reduce the stress a little bit. And I think without that, you know, having that much over my head would make it hard to do this, you know? It has to stay fun, right?Corey: That's part of the things that kept me from, honestly, getting into tech for the first part of my 20s. It was the fear that I would be taking a hobby, something that I love, and turning it into something that I hated.Lex: Yeah, there is that.Corey: It's almost 20 years now and I'm still wondering whether I actually succeeded or not in avoiding hating this.Lex: Well, okay. But I mean, are you, you know, are you depressed [unintelligible 00:09:16] so there's this other thing, there's this thing that people like to say, which is like, “You should only do a job that you really love.” And I used to think that. And I don't actually think that anymore. I think that it is important to have a job that you can do and not hate day-to-day, but there's no shame in not being passionate about your work and I don't think that we should require passion from anyone when we're hiring. And I think to do so is even, like, privilege. So, you know, I think that it's totally fine to just do something because it pays the bills.Corey: Oh, absolutely. I find it annoying as hell when I'm talking to folks who are looking to hire for roles and, “Well, include a link to your GitHub profile,” is a mandatory field. It's, well, great. What about people who work in places where they're not working on open-source projects as a result, and they can't really disclose what they're doing? And the expectation that oh, well outside of work, you should be doing public stuff, too.It's, I used to do a lot of public open-source style work on GitHub, but I got yelled at all the time for random, unrelated reasons and it's, I don't want to put something out there that I have to support and people start to ask me questions about. It feels like impromptu unasked-for code review. No, thanks. So, my GitHub profile looks fairly barren.Lex: You mean like yelling at you, like, “Oh, you're not contributing enough.” Or, you know, “We need this free thing you're doing, like, immediately,” or that kind of thing?Corey: Worse than that. The worst example I've ever had for this was when I was giving a talk called “Terrible Ideas in Git,” and because I wanted to give some hilariously contrived demos that took a fair bit of work to set up, I got them ready to go inside of a Docker container because I didn't trust that my laptop would always work, I'm might have to borrow someone else's, I pushed that image called “Terrible Ideas” up to Docker Hub. And I wound up with people asking questions about it. Like, “Is this vulnerable to ShellCheck.” And it's, “You do realize that this is intentionally designed to be awful? It is only for giving a very specific version of a very specific talk. It's in public, just because I didn't bother to make it private. What are you doing? Please tell me you're not running this in production at a bank?” “No comment.” Right. I don't want that responsibility of people yelling at me for things I didn't do on purpose. I want to get yelled at for the things I did intentionally.Lex: Exactly. It's funny that sometimes people expect more out of you when you're giving them something free versus when they're paying you for it. It's an interesting quirk of psychology that I'm sure that professionals could tell me all about. Maybe there's been research on it, I don't know. But yeah, that can be difficult.Corey: Oh, absolutely. I used to work at a web hosting company and the customer spending thousands a month with us were uniformly great. But there was always the lowest tier customer of the cheapest thing that we offered that seemed to expect that that entitle them to 80 hours a month of support from engineering problems and whatnot. And it was not profitable to service some of those folks. I've also found that there's a real transitive barrier that begins as soon as you find a way to charge someone a dollar for something.There's a bit of a litmus test of can you transfer a dollar from your bank account to mine? And suddenly, the entire tenor of the conversations with people who have crossed that boundary change. I have toyed, on some level, with the idea of launching a version of this newsletter—or wondering if I retcon the whole thing—do I charge people to subscribe to this? And the answer I keep coming away with is not at all because it started in many respects is marketing for AWS bill consulting and I want the audience as fast as possible. Artificially limiting its distribution via a pay-for model just seemed a little on the strange side.Lex: Yeah. And then you're beholden to a very many people and there's that disproportionality. So, years ago, before I even started in my career in I guess, you know, things that were SRE before SRE was cool, I worked for a living in Second Life. Are you familiar with Second Life?Corey: Oh, yes. I'm very familiar with that. Linden Labs.Lex: Yep. So, I worked for Linden Lab years later, but before I worked for them, I sort of spent a lot of my time living in Second Life. And I had a product that I sold for two or three dollars. And actually, it's still in there; you could still buy it. It's interesting. I don't know if it's because the purchase price was 800 Linden dollars, which equates to, like, $2.16, or something like that, but—Corey: The original cryptocurrency.Lex: Right, exactly. Except there's no crypto involved.Corey: [laugh].Lex: But people seem to have a disproportionate amount of, like, how much of my time they expected for support. You know, I'm going to support them a little bit. You have to recognize at some point, I actually can't come give you a tutorial on using this product because you're one of 500 customers for this month. And you give me two dollars and I don't have ten hours to give you. You know, like, sorry [laugh]. Yeah, so that can be really tough.Corey: And on some level, you need to find a way to either charge more or charge for support on top of it, or ideally—it I wish more open-source projects would take this approach—“Huh. We've had 500 people asking us the exact same question. Should we improve our docs? No, of course not. They're the ones who are wrong. It's the children who are getting it wrong.”I don't find that approach [laugh] to be particularly useful, but it bothers me to no end when I keep running into the same problem onboarding with something new and I ask about it, and, “Oh, yeah, everyone runs into that problem. Here's how you get around it.” This would have been useful to mention in the documentation. I try not to ask questions without reading the manual first.Lex: Well, so there's a couple different directions. I could go with this. First of all, there's a really interesting thing that happened with the core-js project that I recommend people check out. Another thing that I think the direction I'll go at the moment—we can bookmark that other one, but I have an open-source project on the side that I kind of did for my own fun, which is a program for creating designs that can be processed by computer-controlled embroidery machines. So, this is sewing machines that can plot stitches in the x-y plane based on a program that you give it.And there really wasn't much in the way of open-source software available that could help you create these designs and so I just sort of hack something together and started hacking with Python for my own fun, and then put it out there and open-sourced. And it's kind of taken off, kind of like gotten a life of its own. But of course, I've got a newsletter, I've got three kids, I've got a family, and a day job, and I definitely hear you on the, like, you know, yeah, we should put this FAQ in the docs, but there can be so little time to even do that. And I'm finding that there's, like—you know, people talk about work-life balance, there's, like, work slash life slash open-source balance that you really—you know, you have to, like, balance all three of them.And a lot of weeks, I don't have any time to spend on the project. But you know what, it's still kicks along and people just kind of, they use my terrible little project [laugh] as best they can, even though it has a ton of rough edges. I'm sorry, everyone, I'm so sorry. I know it has a t—the UI is terrible. But yeah, it's interesting how these things sometimes take on a life of their own and you can feel dragged along by your own open-source work, you know?Corey: It always bothers me—I think this might tie back to the core-js issue you talked about a second ago—where there are people who are building and supporting open-source tools or libraries that they originally constructed to scratch an itch and now they are core dependencies of basically half the internet. And these people are still wondering on some level, how do I put food on the table this month? It's wild to me. If there were justice in the world, you'd start to think these people would wind up in never-have-to-work-again-if-they-don't-want-to positions. But in many cases, it's exactly the opposite.Lex: Well, that's the really interesting thing. So, first of all, I'm hugely privileged to have any time to get to work on open-source. There's plenty of people that don't, and yeah, so requiring people to have a GitHub link to show their open-source contributions is inherently unfair and biased and discriminatory. That aside, people have asked all along, like, “Lex, this is decent software, you could sell this. You could charge money for this thing and you could probably make a, you know, a decent living at this.”And I categorically refuse to accept money for that project because I don't want to have to support it on a commercial level like that. If I take your money, then you have an expectation that—especially if I charge what one would expect—so this software, part of the reason I decided to write my own is because it starts at two-hundred-some-off dollars for the competitors that are commercial and goes up into the five, ten-thousand dollars. For a software package. Mine is free. If I started charging money, then yeah, I'm going to have to build a support department and we're going to have a knowledge base, I'm going to have to incorporate. I don't want to do that for something I'm doing for fun, you know? So yeah, I'm going to keep it free and terrible [laugh].Corey: It becomes something you love, turns into something you hate without even noticing that it happens. Or at least something that you start to resent.Lex: Yeah. I don't think I would necessarily hate machine embroidery because I love it. It's an amazingly fun little quirky hobby, but I think it would definitely take away some of the magic for me. Where there's no stress at all, I can spend months noodling on an algorithm getting it right, whereas it'd be, you know, if I start having to have deliverables, it changes it entirely. Yeah.Corey: It's odd, it seems, on some level too, that the open-source world that I got started with has evolved in a whole bunch of different ways. Whereas it used to be write a quick fix for something and it would get merged, in many cases by the time you got back from lunch. And these days, it seems like it takes multiple weeks, especially with a corporate-controlled open-source project, and there's so much back and forth. And even getting the boilerplate, like the CLI—the Contributor License Agreement—aside and winding up getting other people to sign off on it, then there's back and forth, in some cases for weeks about, well, the right kind of test coverage and how to look at this and the right holistic framework. And I appreciate that there is validity and value to these things, but is that the bulk of the effort should be going when there's a pull request ready to go that solves a breaking customer problem?But the test coverage isn't right so we're going to delay it for two or three releases. It's what are you doing there? Someone lost the plot somewhere. And I'm sure there are reasons that makes sense, given the framework people are operating within. I just find it maddening from the side of having to [laugh] deal with this as a human.Lex: Yeah, I hear you. And it sometimes can go even beyond test coverage to something like code style, you know? It's like, “Oh, that's not really in the style of this project,” or, “You know, I would have written it this way.” And one thing I've had to really work on, on this project is to make it as inviting to developers as possible. I have to sometimes look at things and be like, yeah, I might do that a different way. But does that actually matter? Like, do I have a reason for that that really matters or is it just my style? And maybe because it's a group project I should just be like, no, that's good as it is.[midroll 00:20:23]Corey: So, you've had an interesting career. And clearly you have opinions about SRE as a result. When I started seeing that you were the author of SRE Weekly, years ago, I just assumed something that I don't believe is true. Is it possible that you have been contributing to the community around SRE, but somehow have never worked at Google?Lex: I have never worked at Google. I have never worked at Netflix. I've never worked at any of those big companies. The biggest company I've worked for is Salesforce. Although I worked for Heroku who had been bought by Salesforce a couple of years prior, and so it was kind of like working for a startup inside a big company. And here's the other thing. I created that newsletter two months after starting my first job where I had a—like, the first job in which I was titled ‘SRE.' So, that's possibly contentious right there.Corey: You know, I hadn't thought of it this way, but you're right. I did almost the exact same thing. I was no expert in AWS when I started these things. It came out of an effort that I needed to do of keeping touch with everything that came out that had potential economic impact, which it turns out are most things when you understand architecture and cost are the same thing when it comes to cloud. But I was more or less gathering what smart people were saying.And somehow there's been this osmotic effect, where people start to view me as the wise old sage of the mountain when it comes to AWS. And no, no, no, I'm just old and grumpy. That looks alike. Don't mistake it for wisdom. But people will now seek me out to get my opinion on things and I have no idea what the answer looks like for most of the stuff.But that's the old SRE model—or sysadmin model that I've followed, which is when you don't know the answer, well, how do you get to a place where you can find the answer? How do you troubleshoot this? Click the button. It doesn't work? Well, time to start taking the button apart to figure out why.Lex: Yeah, definitely. I hear you on people. So, first of all, thanks to everyone who writes the articles that I include. I would be nothing without—I mean—literally, that I could not have a newsletter without content creators. I also kind of started the newsletter as an exploration of this new career title.I mean, I've been doing things that basically fit along with SRE for a long time, but also, I think my view of SRE might be not really the same as a lot of folks, or, like, that Google passed down from the [Google Book Model 00:22:46]. I don't—I'm going to be a little heretical here—I don't necessarily a hundred percent believe in the SLI SLO SLA error budget model. I don't think that that necessarily fits everyone, I'm not sure even suits the bigger companies as well as they think it does. I think that there's a certain point to which you can't actually predict failure and just slowing down on your deploys. And it likes to cause there to be fewer incidents so that you can get—your you know, you can go back to passing in your error budget, to passing your SLO, I'm not sure that actually makes sense or is realistic and works in the real world.Corey: I've been left with the distinct impression that it's something of a framework for how to think about a lot of those things. And it's for folks on a certain point of their development along whatever maturity model or maturity curve you want to talk about, it becomes extraordinarily useful. And at some point, it feels like the path that a given company is on will deviate from that. And, on some level, if you don't wind up addressing it, it turns into what it seems like Agile did, where you wind up with the Cult of Agile around it and the entire purpose of it is to perpetuate the Cult of Agile.And I don't know that I'm necessarily willing to go so far as to say that's where SLOs are headed right now, but I'm starting to get the same sort of feeling around the early days of the formalization of frameworks like that, and the ex cathedra proclamation that this is right for everyone. So, I'm starting to wonder whether there's a reckoning, in that sense, coming down the road. I'm fortunate that I don't run anything that's production-facing, so for me, it's, I don't have to care about these things. Mostly.Lex: Yeah. I mean, we are in… we're in 2023. Things have come so much further than when I was a kid. I have a little computer in my pocket. Yeah, you know, “Hey, math teacher, turns out yeah, we do carry calculators around with us wherever we go.” We've built all these huge, complicated systems online and built our entire society around them.We're still in our infancy. We still don't know what we're doing. We're still feeling out what SRE even is, if it even makes sense, and I think there's—yeah, there's going to be more evolution. I mean, there's been the, like, what is DevOps and people coining the term DevOps and then getting, you know, almost immediately subsumed or turned into whatever other people want. Same thing for observability.I think same thing for SRE. So honestly, I'm feeling it out as I go and I think we all are. And I don't think anyone really knows what we're doing. And I think that the moment we feel like we do is probably where we're in trouble. Because this is all just so new. Look where we were even 40 years, 30, even 20 years ago. We've come really far.Corey: For me, one of the things that concerns slash scares me has been that once someone learns something and it becomes rote, it sort of crystallizes in amber within their worldview, and they don't go back and figure out, “Okay, is this still the right approach?” Or, “Has the thing that I know changed?” And I see this on a constant basis just because I'm working with AWS so often. And there are restrictions and things you cannot do and constraints that the cloud provider imposes on you. Until one day, that thing that was impossible is now possible and supported.But people don't keep up with that so they still operate under the model of what used to be. I still remember a year or so after they raised the global per-resource tag limit to 50, I was seeing references to only ten tags being allowed per resource in the AWS console because not even internal service teams are allowed to talk to each other over there, apparently. And if they can't keep it straight internally, what hope to the rest of us have? It's the same problem of once you get this knowledge solidified, it's hard to keep current and adapt to things that are progressing. Especially in tech where things are advancing so rapidly and so quickly.Lex: Yeah, I gather things are a little feudalistic over inside AWS, although I've never worked there, so I don't know. But it's also just so big. I mean, there's just—like, do you even know all of the—like, I challenge you to go through the list of services. I bet you're going to find when you don't know about. You know, the AWS services. Maybe that's a challenge I would lose, but it's so hard to keep track of all this stuff with how fast it's changing that I don't blame people for not getting that.Corey: I would agree. We've long since passed the point where I can talk incredibly convincingly about AWS services that do not exist and not get called out on it by AWS employees. Because who would just go and make something up like that? That would be psychotic. No one in the right mind would do it.“Hi, I'm Corey, we haven't met yet. But you're going to remember this, whether I want you to or not because I make an impression on people. Oops.”Lex: Yeah. Mr. AWS Snark. You're exactly who I would expect to do that. And then there was Hunter, what's his name? The guy who made the—[singing] these are the many services of AWS—song. That was pretty great, too.Corey: Oh, yeah. Forrest Brazeal. He was great. I loved having him in the AWS community. And then he took a job, head of content over at Google Cloud. It's, well, suddenly, you can't very well make fun of AWS anymore, not without it taking a very different tone. So, I feel like that's our collective loss.Lex: Yeah, definitely. But yeah, I feel like we've done amazing things as a society, but the problem is that we're still, like, at the level of, we don't know how to program the VCR as far as, like, trying to run reliable services. It's really hard to build a complex system that, by its nature of being useful for customers, it must increase in complexity. Trying to run that reliably is hugely difficult and trying to do so profitably is almost impossible.And then I look at how hard that is and then I look at people trying to make self-driving cars. And I think that I will never set foot in one of those things until I see us getting good at running reliable services. Because if we can't do this with all of these people involved, how do I expect that a little car is going to be—that they're going to be able to produce a car that can drive and understand the complexities of navigating around and all the hazards that are involved to keep me safe.Corey: It's wild to me. The more I learned about the internet, the more surprised I am that any of it works at all. It's like, “Well, at least you're only using it for ridiculous things like cat pictures, right?” “Oh, no, no, no. We do emergency services and banking and insurance on top of that, too.” “Oh, good. I'm sure that won't end horribly one day.”Lex: Right? Yeah. I mean, you look at, like—you look at how much of a concerted effort towards safety they've had to put in, in the aviation industry to go from where they were in the '70s and '80s to where we are now where it's so incredibly safe. We haven't made that kind of full industry push toward reliability and safety. And it's going to have to happen soon as more and more of the services we're building are, exactly as you say, life-critical.Corey: Yeah, the idea of having this stuff be life-critical means you have to take a very different approach to it than you do when you're running, I don't know, Twitter for Pets. Though, I probably need a new fake reference startup now that Twitter for reality is becoming more bizarre than anything I can make up. But the idea that, “Well, our ad network needs to have the same rigor and discipline applied to it as the life support system,” maybe that's the wrong framing.Lex: Or maybe it's not. I keep finding instances of situations—maybe not necessarily ad networks, although I wouldn't put it past them—but situations where a system that we're dealing with becomes life-critical when we had no idea that it could possibly do. So, for example, a couple companies back, there was this billing situation where a vendor of ours accidentally nilled our customers incorrectly and wiped bank accounts, and real people were unable to make their mortgage payments and unable to, like, their bank accounts were empty, so they couldn't buy food. Like, that's starting to become life-critical and it all came down to a single, like, this could have been any outage at any company. And that's going to happen more and more, I think.Corey: I really want to thank you for taking time to speak with me. If people want to learn more, where's the best place for them to find you?Lex: sreweekly.com. You can subscribe there. Thank you so much for having me on. It has been a real treat.Corey: It really has. You'll have to come back and we'll find other topics to talk about, I'm sure, in the very near future. Thank you so much for your time. I appreciate it.Lex: Thanks.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.

Mitch and Blake discuss the recurring industry obsession with the idea of virtual reality, beginning in the mid-1980s. Mitch recounts a story about his encounter with VPL and the weird world of digital artists and promoters in the early days of personal computing. They look at the second failed wave of VR investment in the 1990s and the importance of Neal Stephenson's Snow Crash. Mitch talks about how Linden Lab's Second Life anticipated many of the ideas of the modern metaverse. They then look at the Oculus, and Facebook's decade-long failure to generate momentum behind a new wave of virtual reality, and what Apple's entry into the market may mean. They conclude with a look at the idea of the metaverse and its challenges. Links and Show Notes: Mondo 2000 magazine Mark Pauline - Survival Research Labs Neuromancer (William Gibson, 1984) “Spawn of Atari” (Wired Magazine) VPL “Murder She Wrote” VR Episode Hasbro's Toaster VR Project Snow Crash (Neal Stephenson, 1993) Ready Player One (Ernest Cline, 2011) Beat Saber The Metaverse (Matthew Ball, 2022) Raph Koster's “real talk about a real metaverse”  

Everett Harper is the CEO and Co-Founder of Truss, a human-centered software development company. He is the author of the new leadership book Move to the Edge, Declare it Center, which was published by Wiley earlier this year. He was previously Director of Customer Acquisition and Community at Linden Lab (maker of Second Life). A CEO and technologist who also hits many stages around the world to talk about Diversity, Equity and Inclusion. On this episode, Everette speaks with AfroTech's Will Lucas about corporate diversity responsibility, the 'Back To Office' trend, and finding startup ideas. Follow Will Lucas on Instagram at @willlucas Learn more at AfroTech.com https://instagram.com/afro.tech Learn more about your ad-choices at https://www.iheartpodcastnetwork.comSee omnystudio.com/listener for privacy information.

Episode 317 features Everett Harper, the CEO, and co-founder of Truss, a human-centered software development company, named as an Inc 5000 fastest-growing private company for 2020 and 2021. He is the author of the new book, "Move to the Edge, Declare It Center".Find the book here - https://www.amazon.com/Move-Declare-Center-Everett-Harper/dp/1119849888Find Everett Online:Website: https://www.everettharper.com/Linkedin: https://www.linkedin.com/in/everettharper/Instagram: https://www.instagram.com/everettharper/Twitter: https://twitter.com/everettharperAbout Everett:Everett Harper is the CEO and co-founder of Truss, a human-centered software development company, named as an Inc 5000 fastest-growing private company for 2020 and 2021. He is a rare combination of a Black entrepreneur, Silicon Valley pedigree, National Champion, and a proven record for solving complex problems with social impact.He had the foresight to build a company that's been remote-first since 2011, and salary-transparent since 2017, anticipating the importance of hybrid work and diversity, equity, and inclusion (DEI) by a decade. Before Truss, Everett was at Linden Lab, maker of Second Life, a pioneering virtual world, and Bain and Company management consultants.Though both his parents had pioneering careers as software programmers for IBM, Everett is the first in his family to attend college, as an A.B. Duke Scholar at Duke University. While majoring in biomedical and electrical engineering at Duke, he also won an NCAA National Championship in soccer. He was inducted into the North Carolina Soccer Hall of Fame in 2019. Everett graduated with an MBA and an M.Ed in Learning, Design, and Technology from Stanford University.In his career, he's leveraged his education and experience to help millions of others, from helping fix healthcare.gov at Truss, fighting poverty worldwide as a Board Member of CARE, and helping low- and moderate-income homebuyers while at Self-Help, a community development finance institution.Everett's distinctive voice and unique history make him a sought-after speaker on leadership, remote work, DEI, and social entrepreneurship. He has been featured at conferences such as Dent, Tugboat, TechStars, and Velocity, podcasts like the Commonwealth Club and AfroTech, and writing for Forbes, Thrive Global, and TechCrunch. Move to the Edge, Declare it Center is his first book, to be published by Wiley in March 2022.Everett grew up a small-town kid in New York's Hudson Valley. He currently lives in Oakland, CA, making limoncello when life hands him lemons.........Thank you for listening! If you wanted to learn more about the host, Brian Ondrako, check out his “Now” Page - https://www.brianondrako.com/now or Sign up for his Weekly Newsletter and 3x a Week Blog - https://brianondrako.com/subscribe/ Hosted on Acast. See acast.com/privacy for more information.

Philip Rosedale is the founder of Linden Lab, which launched the popular virtual world Second Life in 2003. His goal has always been to build a viable model for a virtual economy or virtual society, not just an entertainment platform. Before Second Life he served as CTO at RealNetworks, where he wrote some of the earliest algorithms to compress video for transmission across the internet. In 2013 he founded High Fidelity, which builds a spatial audio for group chat. He is currently involved with both Second Life and High Fidelity, and advises on Metaverse efforts.

Emma and Christy play The Sims 4 Paranormal ‘Stuff Pack', exploring the game's haunted house and séance aesthetics. We talk Victorian occult imaginaries, playing Sims as an emotional outlet, the promise of perfect capitalism, video games and affect, queer computer spaces, technopagans and cyber covens, and esoteric beliefs on the internet. CLICK HERE TO VIEW THE IMAGES WE DISCUSS, as well as complete show notes, references, and suggestions for further reading. MEDIA DISCUSSED All screenshots from The Sims 4 Paranormal can be found, in order of discussion, in the image carousel on the episode page linked above. Electronic Arts, The Sims 4 Paranormal ‘Stuff Pack' (2021) Jordan Peele, Get Out (2017) Jean-Marc Vallée, Sharp Objects (2018) Solomon J. Solomon, A Conversation Piece (1884) The green ghost, ‘Slimer', from: Ivan Reitman, Ghostbusters (1984) Electronic Arts, ‘Can a computer make you cry' advertisement (1983) ‘Miss Calendar' from: Joss Whedon, Buffy the Vampire Slayer (1997-2003) Linden Lab, Second Life (first released 2003) CREDITS This season of ‘Drawing Blood' was funded in part by the Association for Art History. Follow our Twitter @drawingblood_ Audio postproduction by Sias Merkling ‘Drawing Blood' cover art © Emma Merkling All audio and content © Emma Merkling and Christy Slobogin Intro music: ‘There Will Be Blood' by Kim Petras, © BunHead Records 2019. We're still trying to get hold of permissions for this song – Kim Petras text us back!!

When Second Life officially launched in 2003, it had one guiding principle for all new users: Be Nice. But those users showed up with their own ideas about how to behave in a virtual world. In Part 2 of How to Build a Metaverse, Linden Lab — the company that created Second Life — wrestles with how to govern its new world. Learn more about your ad choices. Visit megaphone.fm/adchoices

Nearly two decades before companies like Meta began pouring billions of dollars into the metaverse, a little company called Linden Lab already had one. In Part 1 of our series, we meet the programmers who built Second Life -- a 3-D virtual world where users could be and do whatever they could imagine. And we meet the intrepid users who were the pioneers of this brave new world. Learn more about your ad choices. Visit megaphone.fm/adchoices

Founder of Second Life Philip Rosedale shares his thoughts on what virtual worlds can teach us about being human, the relationship between Second Life users and their avatars, and the challenges of building the metaverse using Web 3.0 technologies. Philip Rosedale is the Founder of Linden Lab, parent company of Second Life, an open-ended, Internet-connected virtual world and pioneering metaverse. Following Second Life, he worked on several projects related to distributed work and computing. Excited by innovations in these areas and the proliferation of new VR-enabling devices, he re-entered the virtual worlds space in 2013, co-founding High Fidelity, a company devoted to exploring the future of next-generation shared virtual reality. Philip rejoined Second Life in 2022, as Strategic Advisor, focused on helping to shape and build a better metaverse. Find out more: futurespodcast.net Credits Produced by FUTURES Podcast Recorded, Mixed & Edited by Luke Robert Mason Follow Us Twitter: twitter.com/futurespodcast Facebook: facebook.com/futurespodcast Instagram: instagram.com/futurespodcast

Everett Harper is the CEO and Co-Founder of Truss, a human-centered software development company. He is the author of the new leadership book Move to the Edge, Declare it Center, which was published by Wiley earlier this year. He was previously Director of Customer Acquisition and Community at Linden Lab (maker of Second Life). A CEO and technologist who also hits many stages around the world to talk about Diversity, Equity and Inclusion. On this episode, Everette speaks with AfroTech's Will Lucas about corporate diversity responsibility, the 'Back To Office' trend, and finding startup ideas. Follow Will Lucas on Instagram at @willlucas Learn more at AfroTech.com https://instagram.com/afro.tech Learn more about your ad-choices at https://www.iheartpodcastnetwork.com  See omnystudio.com/listener for privacy information.

If you've ever wrestled with technology choices & navigated the consequences of the wrong path… this conversation is for you! Lisa Dusseault (CTO @ Compaas) defines the dilemma of the “aspirational mismatch” & shares real-life examples of how it affects a tech org's processes, architecture, and metrics. She dives into the frameworks & tools that have helped her work through mismatches, her golden rule regarding “innovation tokens,” choosing the right sized technology for your company, and why tech companies are prone to aspirational mismatch in the first place.ABOUT LISA DUSSEAULTLisa Dusseault is the Chief Technology Officer at Compaas. She has built her career solving complex technology problems. After Microsoft, she led internet standards groups at the IETF, and engineering teams at Linden Lab and Stubhub. She founded tech startups Cathy Labs, Klutch, and ShareTheVisit. Lisa holds a B.S. in systems design engineering from University of Waterloo."The conversation should have been about when and why this company needed a particular technology choice, not whether a technology choice was good in and of itself."- Lisa Dusseault   This episode is brought to you by JellyfishFor insights into where engineering teams are investing their time and resources, how they're operating and performing, and the way in which leaders are managing today…Download “The State of Engineering Management Report 2022” HERE:jellyfish.co/emrTo understand how your engineering org compares against teams from across the industry and gain data-driven metrics to inform your strategic decisions regarding the right tools, processes and workflows…Learn More About Jellyfish Benchmarks @ jellyfish.co/benchmarksSHOW NOTES:Defining aspirational mismatch & its detrimental impact on eng orgs (02:10)What “cargo culting” is & why it's a decision-making flaw (4:18)How aspirational mismatch manifests in eng orgs (5:48)The importance of tech companies asking the questions “when” & “why” (7:39)Examples of how eng orgs experience aspirational mismatch in their tech choices (9:08)Framework for tying your metrics to your org's business objectives (12:33)How metrics can inform frontline decisions (14:15)Choose a technology that's the correct size for your org (16:19)The cost of merging & compounding mismatches (19:28)Lisa's golden rule regarding “innovation tokens” for tech start-ups (21:07)Why eng orgs need a unified vision to avoid aspirational mismatch in processes (23:52)Using epics to communicate company vision (26:37)Where aspirational mismatches come from & why eng teams experience them (29:10)Recommendations for withstanding aspirational technology pressure (32:11)Additional frameworks for working through mismatches (34:33)How to host conversations around realistically planning for future aspirations (37:02)Rapid fire questions (39:55)

About the author Everett Harper is the CEO and Co-Founder of Truss, a human-centered software development company, named as an Inc 5000 fastest-growing private company for 2020 and 2021. He is a rare combination of a Black entrepreneur, Silicon Valley pedigree, National Champion, and a proven record for solving complex problems with social impact. He had the foresight to build a company that's been remote-first since 2011, salary-transparent since 2017, anticipating the importance of hybrid work and diversity, equity and inclusion (DEI) by a decade. Before Truss, Everett was at Linden Lab, maker of Second Life, a pioneering virtual world, and Bain and Company management consultants. Though both his parents had pioneering careers as software programmers for IBM, Everett is the first in his family to attend college, as an A.B. Duke Scholar at Duke University. While majoring in biomedical and electrical engineering at Duke, he also won a NCAA National Championship in soccer. He was inducted into the North Carolina Soccer Hall of Fame in 2019. Everett graduated with an MBA and a M.Ed in Learning, Design and Technology from Stanford University. In his career, he's leveraged his education and experience to help millions of others, from helping fix healthcare.gov at Truss, fighting poverty worldwide as a Board Member of CARE, and helping low- and moderate-income homebuyers while at Self-Help, a community development finance institution. Everett grew up a small town kid in New York's Hudson Valley. He currently lives in Oakland, CA, making limoncello when life hands him lemons. Source: https://www.everettharper.com/about   About the book Lead organizations, solve problems, and sustain growth with effective practices for complex, uncertain, and unpredictable environments. Renowned CEO and strategist Everett Harper explores practical techniques for making pivotal decisions through uncertainty in Move to the Edge, Declare it Center—a pragmatic playbook for leaders solving complex problems in high-pressure environments. You'll discover a collection of practices, processes, and infrastructure that can be applied to your own circumstances and scaled throughout your organization. The author's framework—which is perfectly suited to an increasingly volatile, uncertain, and unpredictable business environment—offers effective ways to make decisions without complete information. It demonstrates how to sustain a team through uncertain and stressful periods while managing personal anxiety. The book includes case studies from World Central Kitchen, policymakers responding to Covid-19, and California wildfire fighters, adaptable playbooks on salary transparency, remote work, and diversity and inclusion, and personal stories from the author that describe strategies for maintaining high performance and avoiding burnout. An indispensable guide to modern business leadership, Move the the Edge, Declare it Center is a one-of-a-kind discussion of effective, modern strategies to deal with complex problems in the face of uncertain outcomes. Source: https://www.everettharper.com/about-the-book Big idea #1 – Move to the EdgeThe whole idea of move to the edge, declare it centre was inspired by a quote about Andy Warhol; “Move to the edge, declare it centre and let the world reorganise itself around you”.  Everett and his team did just this, even if it took the world a decade to catch on with things like being a remote first workplace, which they started doing way back in 2011.   This whole approach is one of responding to complexity, and using interior and exterior practices to do that. Move to the edge specifically, is the practices, processes, and infrastructure to address complex problems. Its methodology involves being at the edge of your knowledge and the unknown, in that liminal space between the two. It's where you need to get curious; you're looking for insights, running experiments, and thinking about how you can find out new things and see different perspectives. The more expert or experienced you are, the more you need to do this. It is equivalent to things like Tiger Woods changing his swing several times during his very successful career, or Michael Jordan making a late-career jump shot change. These things force a new perspective, no matter how far into your career you are. Big idea #2 – Declare it CentreDeclare it centre is about building operations to systemise, scale and share innovations so that they can deliver the desired outcome. It's this that enables the individuals, teams, companies, and organisations to sustain the work with less individual effort. A great example of this in the book is painting the Golden Gate Bridge. Every single year on exactly the same day, they start painting the Golden Gate Bridge. Everything is done exactly the same as the year before, to the day, and once it's done, they are ready to do it again the following year in the same way and on the exact same day. Systemising and scaling ways of working so that you can repeat them allows you to sustain the work.   Another great example Everett talks about is the Montgomery bus boycott of 1955 to 1956 that lasted 382 days. In advance, Rosa Parks and her compatriots were training in the Highlander centre and the Smoky Mountains of Tennessee for years to get ready to sustain themselves. They had to create plans and infrastructure and build relationships to make sure it was sustainable; to move forward they had to build a whole system around it.   Systemic change requires sustained effort. Big idea #3 – Being Human TogetherBeing humans together is something very specific to the way that Truss choose to work. At Truss, they have a weekly 30-minute meeting just for a chat, to learn about each other and encourage conversation on different topics.   Move to the edge, declare it centre creates better human and diverse conversations. It forces you to hear new views and have access to experiences you haven't always aligned with or lived. Everett talks about if you grew up on the edge, because of where you were born, your race, your culture, your gender, or your sexual identity, you're in a great position to say “this thing was not designed for people like me”.  Whereas if you grew up in the centre, you have the opportunity to move to the edge and let the centre be someone else, and you can listen to their perspectives and then design products / services accordingly. This requires the use of internal practices to overcome those voices or discomfort that you will naturally experience as a result of moving to the edge and having some things disrupted in your mind around what is true and what is right. Everett has a great quote in the book - The new normal is complex, train for it. Support my book habit: https://www.buymeacoffee.com/stephsbookshelfSee omnystudio.com/listener for privacy information.

Today on the Alt Goes Mainstream podcast we have a guest who helps us bridge the gap between the past, the present, and the future.Ethan Kurzweil, a Partner at Bessemer Venture Partners, who is leading BVP's crypto efforts and the BessemerDAO, comes onto the show to help us make sense of the evolution from the Web2 to Web2.5 to Web3 world.Ethan and I had a fascinating discussion. We talked about:  The evolution of venture capital and private markets.  Bessemer's thesis on Web3. Why Bessemer decided to start a DAO and how they are innovating on portfolio services by building out a community.  How Web3 gives people the primitives to fulfill on the premise of decentralization and ownership. Bessemer is a storied venture fund that got its start back in 1975 after spinning out of Bessemer Trust. Fast forward to today, they are one of the best technology investors on the planet investing into industry defining companies like Shopify, Twilio, PagerDuty, DocuSign, LinkedIn, Twitch, Yelp, Wix, Sorare, and many more.Ethan brings a fascinating perspective to the world of Web3 and consumerization of private markets investing given that he spent the early days of his career at early metaverse company Linden Lab, the creator of Second Life, and working for Dow Jones, where he managed the turnaround of the international editions of the Wall Street Journal.Ethan then went on to join Bessemer, where he's a Partner investing into developer platforms, data infrastructure, digital consumer applications, and consumer facing crypto. He's invested in the likes of PagerDuty, Intercom, Twitch, LaunchDarkly and crypto companies like Sorare, TRM Labs, and Fold.Thanks Ethan for coming on the Alt Goes Mainstream podcast.

On this episode of Office Hours, Spencer speaks to Philip Rosedale, CEO and cofounder of High Fidelity and founder of Linden Lab, for a wide-ranging conversation about Web 3.0 and the future of the metaverse. Rosedale, who recently rejoined Second Life as a strategic advisor, speaks about his vision on what the future of metaverse holds, and how startups can prepare to innovate around it. As a true pioneer in the early iterations of the metaverse and virtual reality, Rosedale shares what he's learned about the challenges and opportunities that face the growth of what has become the biggest new buzzword in tech. This talk was originally broadcast as a live online discussion on Zoom that took place as part of Madrona Venture Labs “Launchable: Web3 Startups” event on March 18, 2022.

Spring Break season is upon us, and you know what that means… it's time for a philosophical debate?  Sure, let's go with that.  Norah had a question about “Episode 34 - Space” for my guest Paul, so we called her up and recorded her for the program.  We ended up talking about the vastness of space, Ben's lack of knowledge when it comes to automobiles, and the “Metaverse”. 00:00:52 - “It's an uncle-free zone here at the Two Vague Podcast.” 00:02:24 - Norah's 3 hour waitress job and remembering Aunt Pat 00:04:15 - Ben knows nothing about automobile manufacturers  00:06:04 - Norah's question about the universe, and Ben needs mushrooms 00:08:55 - Ben's power move suggestion... Marcus  00:11:10 - Norah's universe in a shoebox, and Ben asks Paul for “space evidence” 00:14:50 - The most mass in a galaxy, and Dads 00:16:18 - Norah has been contemplating the “Metaverse”  00:19:18 - Paul talks about the book Snow Crash by Neal Stephenson 00:21:00 - Ben and Paul try to explain “Second Life” by Linden Lab to Norah  00:23:50 - “Smells of the Metaverse,” and closing the call

Ravi Kumar S., President, Infosys, in conversation with Philip Rosedale, Founder, Linden Lab, discussing opportunities for enterprises in the metaverse.

In episode 17, Henry Holtzman interviews Kavya Pearlman, award-winning cyber security professional and founder of the XR Safety Initiative, a non-profit organization that promotes privacy, security, and ethics in virtual and augmented reality. Henry asks Kavya to break down why there is so much buzz around the metaverse right now, and why we should be concerned for our privacy. Kavya explains how body-worn sensors like VR headsets vastly increase the amount of data companies can collect from users, and the difficulty of developing regulations for technology that doesn't quite exist yet.  Kavya shares her experience serving as the head of security for the oldest existing virtual world, “Second Life” by Linden Lab, and what this taught her about the need for adequate user protections. To learn more about the risks of virtual reality, Kavya suggests this recent report by her organization. To get involved with XRSI, visit https://xrsi.org/volunteer.

Justin Gordon (@justingordon212) talks with Hunter Walk (@hunterwalk) Partner at Homebrew - Providing early-stage investment, assistance & love to entrepreneurs building companies for the Bottom Up Economy. Investments include ShieldAI, Plaid, Gusto, Chime, Cruise, Bowery Farming, and other FinTech, SaaS, API, marketplace, commerce businesses.Before Homebrew, he led consumer product management at YouTube, starting when it was acquired by Google. He originally joined Google in 2003, managing product and sales efforts for AdSense, Google‘s contextual advertising business. His first job in Silicon Valley was as the founding product and marketing guy at Linden Lab. Before graduate school, he was a management consultant and also spent a year at Late Night with Conan O‘ Brien. His parents are proud of his BA in History from Vassar and MBA from Stanford University.Hunter Walk's Twitter: https://twitter.com/hunterwalkTopics Discussed:  Leaving google and launching his own venture Different ways of being an investor Angel investing  Blogging as an investor The value of Twitter Screendoor, an organization supporting underrepresented General Partners of emerging venture capital funds How Hunter's time at Google impacted him More about the show:The Vitalize Podcast, a show by Vitalize Venture Capital (a seed-stage venture capital firm and pre-seed 300+ member angel community open to everyone), dives deep into the world of startup investing and the future of work.Hosted by Justin Gordon, the Director of Marketing at Vitalize Venture Capital, The Vitalize Podcast includes two main series. The Angel Investing series features interviews with a variety of angel investors and VCs around the world. The goal? To help develop the next generation of amazing investors. The Future of Work series takes a look at the founders and investors shaping the new world of work, including insights from our team here at Vitalize Venture Capital. More about us:Vitalize Venture Capital was formed in 2017 as a $16M seed-stage venture fund and now includes both a fund as well as an angel investing community investing in the future of work. Vitalize has offices in Chicago, San Francisco, and Los Angeles.The Vitalize Team:Gale - https://twitter.com/galeforceVCCaroline - https://twitter.com/carolinecasson_Justin - https://twitter.com/justingordon212Vitalize Angels, our angel investing community open to everyone:https://vitalize.vc/vitalizeangels/

Charity Majors is the co-founder and CTO of Honeycomb. Before that she worked at Facebook, Parse and Linden Lab on infrastructure and developer tools, and she always seems to wind up running databases. She is the co-author of "Database Reliability Engineering" and the upcoming "Observability Engineering: Achieving Production Excellence" book published by O'Reilly. Twitter: https://twitter.com/mipsytipsy   LinkedIn: https://www.linkedin.com/in/charity-majors/  Blog: https://charity.wtf/  Honeycomb: https://www.honeycomb.io/ 

Good conversations are taking place around reducing bias and increasing diversity in tech hires.But real change happens when infrastructure is implemented and executed within an organization.Our guest, Everett Harper, is an experienced Infrastructuralist, and has the studies and results to show how tech companies can positively change hiring practices.Everett is co-founder of Truss where, for 10 years, they've been helping startups scale and large enterprises and public agencies transform from legacy to modern systems. Truss made its name by helping to save Healthcare.gov, and since then they've worked with massive health data systems, major transportation and logistics systems, and several companies with data science specializations. Everett's expertise is in customer development, a technique that combines customer behavior with ethnography to inform product and business development.He has an MBA and M.Ed in design and technology from Stanford, and a BSEE in Biomedical and Electrical Engineering from Duke. Everett was a full-tuition AB Duke Scholar and won the NCAA National Championship in soccer, the first in any sport for Duke.To learn more about Truss, please visit their website here: https://truss.works/Follow Truss on social media here:https://twitter.com/truss_works https://www.facebook.com/trussworks/ https://www.linkedin.com/company/trussworksConnect with Everett and follow him everywhere he glows here:LinkedIn: https://www.linkedin.com/in/everettharper/Twitter: https://twitter.com/everettharperIG: https://www.instagram.com/everettharper/?hl=en00:00 - Meet Everett Harper!07:45 - Everett's origin story12:05 - the fails and learnings from Everett's first entrepreneurial adventure 15:00 - Linden Lab https://www.lindenlab.com/18:00 - diving deep into customer development in 2011 during his time with Women's Lab 2.0 - now called W2.0 - https://women2.com - Everett creates a calendar app21:00 - how to inspire potential team members to join your startup26:00 - bootstrapping a startup through customer acquisition30:00 - how to make diversity and inclusion central to a startup's hiring practice from day one and tie it into the business model34:00 - how founders can build their network to include diversity37:48 - how to make sure female engineers feel psychologically safe in the workplace40:04 - what Truss learned from their first Transgender hire to make sure everyone feels welcome and included42:25 - what is ethnography and how you can use it to deepen your customer development45:24 - Everett's thoughtful insights advice for female founders confronted with misogynistic Bro Cultures in the startup community as well as at the office.59:45 - Everett's brilliant founder journey advice: get comfortable with being uncomfortable - Stitch That On A Pillow!Thank you for carving out time to improve your Founder Game - when you do better, your business will do better - cheers!Ande ♥Ande Lyonshttp://andelyons.comANDELICIOUS RESOURCES:JOIN STARTUP LIFE LIVE MEETUP GROUPGet an alert whenever I post a new show!https://bit.ly/StartupLifeLIVEAGORAPULSEMy favorite digital marketing dashboard is AGORAPULSE – it's the best platform to manage your social media posts and presence! Learn more here: http://www.agorapulse.com?via=ande17STARTUP DOX Do you need attorney reviewed legal documents for your startup? I'm a proud community partner of Startup Dox, a new service provided by Selvarajah Law PC which helps you draw out all the essential paperwork needed to kickstart your business in a super cost-effective way. All the legal you're looking for… only without confusion or frustration. EVERY filing and document comes with an attorney review. You will never do it alone. Visit https://www.thestartupdox.com/ and use my discount code ANDE10 to receive 10% off your order.SPONSORSHIPIf you resonate with the show's mission of amplifying diverse founder voices while serving first-time founders around the world, please reach out to me to learn more about making an impact through sponsoring the Startup Life LIVE Show! ande@andelyons.com.STREAMYARD OVERLAYS AND GRAPHIC DESIGNNicky Pasquierhttps://www.virtuosoassistant.co.uk/Visit Nicky's CANVA Playlist: https://www.youtube.com/playlist?list=PLhUDgDHkkma3YhOf7uy8TAbt7HdkXhSjONicky's Canva Presentation Playlist: http://bit.ly/Canva_Present_PlaylistGET VIDEO/AUDIO TRANSCRIBED WITH OTTER.AIhttps://bit.ly/StartupLifeOtter CONNECT WITH ME ONLINE: https://andelyons.com https://twitter.com/AndeLyonshttps://www.facebook.com/StartupLifew... https://www.linkedin.com/in/andelyons/ https://www.instagram.com/ande_lyons/ https://www.pinterest.com/andelyons/ https://angel.co/andelyons TikTok: @andelyons

In this episode, we cover: 00:00:00 - Introduction  00:03:30 - An Engineering Anecdote  00:08:10 - Lessons Learned from Putting Out Fires 00:11:00 - Building “Guardrails” 00:18:10 - Pushing the Chaos Envelope  00:23:35 - OpenGitOps Project 00:30:37 - Where to Find Leo/Costa Rica CNCF Links: Weaveworks: https://www.weave.works GitOps Working Group: https://github.com/gitops-working-group/gitops-working-group OpenGitOps Project: https://opengitops.dev Github.com/open-gitops: https://github.com/open-gitops Twitter: https://twitter.com/murillodigital LinkedIn: https://www.linkedin.com/in/leonardomurillo/ Costa Rica CNCF: https://community.cncf.io/costa-rica/ Cloudnative.tv: http://cloudnative.tv Gremlin-certified chaos engineering practitioner: https://www.gremlin.com/certification TranscriptJason: Welcome to the Break Things on Purpose podcast, a show about our often self-inflicted failures and what we learn from them. In this episode, Leonardo Murillo, a principal partner solutions architect at Weaveworks. He joins us to talk about GitOps, Automating reliability, and Pura Vida.Ana: I like letting our guests kind of say, like, “Who are you? What do you do? What got you into the world of DevOps, and cloud, and all this fun stuff that we all get to do?”Leo: Well, I guess I'll do a little intro of myself. I'm Leonardo Murillo; everybody calls me Leo, which is fine because I realize that not everybody chooses to call me Leo, depending on where they're from. Like, Ticos and Latinos, they're like, “Oh, Leo,” like they already know me; I'm Leo already. But people in Europe and in other places, they're, kind of like, more formal out there. Leonardo everybody calls me Leo.I'm based off Costa Rica, and my current professional role is principal solutions architect—principal partner solutions architect at Weaveworks. How I got started in DevOps. A lot of people have gotten started in DevOps, which is not realizing that they just got started in DevOps, you know what I'm saying? Like, they did DevOps before it was a buzzword and it was, kind of like, cool. That was back—so I worked probably, like, three roles back, so I was CTO for a Colorado-based company before Weaveworks, and before that, I worked with a San Francisco-based startup called High Fidelity.And High Fidelity did virtual reality. So, it was actually founded by Philip Rosedale, the founder of Linden Lab, the builders of Second Life. And the whole idea was, let's build—with the advent of the Oculus Rift and all this cool tech—build the new metaverse concept. We're using the cloud because, I mean, when we're talking about this distributed system, like a distributed system where you're trying to, with very low latency, transmit positional audio, and a bunch of different degrees of freedom of your avatars and whatnot; that's very massive scale, lots of traffic. So, the cloud was, kind of like, fit for purpose.And so we started using the cloud, and I started using Jenkins, as a—and figure it out, like, Jenkins is a cron sort of thing; [unintelligible 00:02:48] oh, you can actually do a scheduled thing here. So, started using it almost to run just scheduled jobs. And then I realized its power, and all of a sudden, I started hearing this whole DevOps word, and I'm like, “What this? That's kind of like what we're doing, right?” Like, we're doing DevOps. And that's how it all got started, back in San Francisco.Ana: That actually segues to one of the first questions that we love asking all of our guests. We know that working in DevOps and engineering, sometimes it's a lot of firefighting, sometimes we get to teach a lot of other engineers how to have better processes. But we know that those horror stories exist. So, what is one of those horrible incidents that you've encountered in your career? What happened?Leo: This is before the cloud and this is way before DevOps was even something. I used to be a DJ in my 20s. I used to mix drum and bass and jungle with vinyl. I never did the digital move. I used DJ, and I was director for a colocation facility here in Costa Rica, one of the first few colocation facilities that existed in the [unintelligible 00:04:00].I partied a lot, like every night, [laugh] [unintelligible 00:04:05] party night and DJ night. One night, they had 24/7 support because we were collocations [unintelligible 00:04:12], so I had people doing support all the time. I was mixing in some bar someplace one night, and I don't want to go into absolute detail of my state of consciousness, but it wasn't, kind of like… accurate in its execution. So, I got a call, and they're like, “We're having some problem here with our network.” This is, like, back in Cisco PIX times for firewalls and you know, like… back then.I wasn't fully there, so I [laugh], just drove back to the office in the middle of night and had this assistant, Miguel was his name, and he looks at me and he's like, “Are you okay? Are you really capable of solving this problem at [laugh] this very point in time?” And I'm like, “Yeah. Sure, sure. I can do this.”We had a rack full of networking hardware and there was, like, a big incident; we actually—one of the primary connections that we had was completely offline. And I went in and I started working on a device, and I spent about half an hour, like, “Well, this device is fine. There's nothing wrong with the device.” I had been working for half an hour on the wrong device. They're like, “Come on. You really got to focus.”And long story short, I eventually got to the right device and I was able to fix the problem, but that was like a bad incident, which wasn't bad in the context of technicality, right? It was a relatively quick fix that I figured it out. It was just at the wrong time. [laugh]. You know what I'm saying?It wasn't the best thing to occur that particular night. So, when you're talking about firefighting, there's a huge burden in terms of the on-call person, and I think that's something that we had experienced, and that I think we should give out a lot of shout-outs and provide a lot of support for those that are on call. Because this is the exact price they pay for that responsibility. So, just as a side note that comes to mind. Here's a lot of, like, shout-outs to all the people on-call that are listening to this right now, and I'm sorry you cannot go party. [laugh].So yeah, that's telling one story of one incident way back. You want to hear another one because there's a—this is back in High Fidelity times. I was—I don't remember exactly what it was building, but it had to do with emailing users, basically, I had to do something, I can't recall actually what it was. They was supposed to email all the users that were using the platform. For whatever reason—I really can't recall why—I did not mock data on my development environment.What I did was just use—I didn't mock the data, I actually used just to a copy of the production [unintelligible 00:07:02] the users. I basically just emailed everybody, like, multiple times. And that was very embarrassing. And another embarrassing scenario was, one day, I was working on a firewall that was local to my office, and I got the terminals mixed up, and I shut down not my local office firewall, but the one that was at the colocation facility. And that was another embarrassing moment. So yeah, those are three, kind of, self-caused fires that required fighting afterwards.Ana: The mock data one definitely resonates, especially when you're starting out in engineering career where you're just like, “Hey, I need to get this working. I'm trying to connect to pull this data from a production service,” or, “I'm trying to publish a new email, I want to see how it all goes out. Yeah, why not grab a copy of what actually usually is being used by my company and, like, press buttons here? Oh, wait, no, that actually is hitting a live endpoint? I did not know that.”Which brings me to that main question; what do you end up learning when you go through these fires? After you went through this incident that you emailed all of your customers, what is something that you learn that you got to take back.Leo: I learned how you have to pay attention. It's hard to learn without having gone through this experiences because you start picking up on cues that you didn't pick up in the past. You start seeing things that you didn't pay attention to before, particularly because you didn't know. And I'm pretty sure, even if somebody would have told me, “Don't do this,” or, “Don't do that. Be careful,” you still make those mistakes.There is certain things that you only achieve through experience. And I think that's one of the most important things that I realized. And I've actually see the analogy of that with my children. There's certain things that I, no matter how well I articulate, they will not learn until they go through those experiences of themselves. But I think that's one of the things that I'd argue, you ha—you will go through this, and it's—it's not okay, but it's okay.Everybody makes mistakes. You'll also identify whether—like, how supporting your team is and how supportive your—the organization you're working with is when you see the reaction to those errors. Hopefully, it wasn't something too bad, and ideally there's going to be guiderails that prevent that really, really bad scenario, but it's okay to make mistakes. You learn to focus through those mistakes and you really should be paying attention; you should never take anything for granted. There is no safety net. Period.So, you should never assume that there is, or that you're not going to make a mistake. So, be very careful. Another thing that I learned, how I can I work in my development environment. How different patterns that I apply in my development environment, how I now I'm very careful to never have, kind of like, production [x 00:10:11] readily available within my development environment. And also to build those guiderails.I think part of what you learn is all the things that could go wrong, might go wrong, so take time to build those guiderails. I think that's important. Like anything else that comes with seniority, when you have a task to accomplish, the task itself is merely a margin, only a percentage of what you really should consider to reach that objective. And a lot of the times, that means building protection around what you're asked, or thinking beyond that scope. And then leverage the team, you know? If you have people around you that know more, which is kind of great about community and collaboration. Like, being—don't—you're not alone.Ana: I love that you mentioned guardrails and guardrails being a way that you're able to prevent some of these things. Do you think something like chaos engineering could help you find those guardrails when you don't know that you don't have a guardrail?Leo: I think it definitely. The more complex your job, the more complex your architecture, the more complex of the solution you're building—and we've gotten in an increase in complexity over time. We went from monoliths to microservices to fully distributed architectures of services. We went from synchronous to asynchronous to event-driven to—like, there's this increase in complexity that is basically there for a reason because of an increase in scale as well. And the number of possible failure conditions that could arise from this hugely diverse and complex set of variables means that we've gotten to a point that likely always was the way, but now it's reached, again, and because of targets aligned with this complexity, new levels of scale, that there is currently more unknown unknowns than we've ever had.The conditions that you can run into because of different problem states of each individual component in your distributed architecture, brings up an orders-of-magnitude increase in the possible issues that you might run into, basically a point where you really have to understand that you have no idea what could fail, and the exercise of identifying what can fail. Or what are the margins of stability of your solution because that's, kind of like, the whole point, the boundaries? There's going to be a set of conditions, there's going to be a combination of conditions that will trigger your—kind of, will tip your solution beyond that edge. And finding those edges of stability can no longer be something that just happens by accident; it has to be premeditated, it has to be planned for. This is basically chaos engineering.Hypothesizing, given a set of conditions, what is the expected outcome? And through the execution of this hypothesis of increasing or varying scope and complexity, starting to identify that perimeter of stability of their solution. So, I guess to answer your question, yes. I mean, chaos engineering allows you to ide—if you think about that perimeter of stability as the guardrails around your solution within which have to remain for your solution to be stable, for instance, there goes—[unintelligible 00:13:48] chaos engineering. I was actually talking to somebody the other day, so I'm the organizer for the Costa Rica Cloud-Native Community, the chapter for [unintelligible 00:14:00], and I have this fellow from [unintelligible 00:14:04] who, he works doing chaos engineering.And he was talking to me about this concept that I had not thought about and considered, how chaos engineering can also be, kind of like, applied at a social level. What happens if a person xyz is not available? What happens if a person other has access to a system that they shouldn't have? All these types of scenarios can be used to discover where more guiderails should be applied.Jason: You know, you start to learn where the on-call person that's completely sober, maybe, is unavailable for some reason, and Leo comes and [crosstalk 00:14:45]—Leo: Right. [laugh]. Exactly. Exactly. That's what you have to incorporate in your experiment, kind of like, the DJ variable and the party parameter.Jason: It's a good thing to underscore as well, right? Back to your idea of we can tell our children all sorts of things and they're not going to learn the lesson until they experience it. And similarly with, as you explore your systems and how they can fail, we can imagine and architecture systems to maybe be resilient or robust enough to withstand certain failures, but we don't actually learn those lessons or actually know if they're going to work until we really do that, until we really stress them and try to explore those boundaries.Leo: Wouldn't it be fantastic if we could do that with our lives? You know, like, I want to bungee jump or I want to skydive, and there's a percentage of probability that I'm going to hit the ground and die, and I can just introduce a hypothesis in my life, jump, and then just revert to my previous state if it went wrong. It would be fantastic. I would try many, many things. [laugh].But you can't. And it's kind of like the same thing with my kids. I would love to be able to say, “You know what? Execute the following process, get the experience, and then revert to before it happened.” You cannot do that in real life, but that's, kind of like, the scenario that's brought up by chaos engineering, you don't have to wait for that production incident to learn; you can actually, “Emulate” quote-unquote, those occurrences.You can emulate it, you can experience without the damage, though, if you do it well because I think that's also part of, kind of like, there's a lot to learn about chaos engineering and there's a lot of progress in terms of how the practice of chaos engineering is evolving, and I think there's likely still a percentage of the population or of the industry that still doesn't quite see chaos engineering beyond just introducing chaos, period. They know chaos engineering from calling the Chaos Monkeys kill instances at random, and fix things and, you know, not in the more scientific context that it's evolved into. But yeah, I think the ability to have a controlled experience where you can actually live through failure states, and incidents, and issues, and stuff that you really don't want to happen in real life, but you can actually simulate those, accelerates learning in a way that only experience provides. Which is the beauty of it because you're actually living through it, and I don't think anything can teach us as effectively as living through [unintelligible 00:17:43], through suffering.Ana: I do also very much love that point where it's true, chaos engineering does expedite your learning. Not only are you just building and releasing and waiting for failure to happen, you're actually injecting that failure and you get to just be like, “Oh, wait, if this failure was to occur, I know that I'm resilient to it.” But I also love pushing that envelope forward, that it really allows folks to battle-test solutions together of, “I think this architecture diagram is going to be more resilient because I'm running it on three regions, and they're all in just certain zones. But if I was to deploy to a different provider, that only gives me one region, but they say they have a higher uptime, I would love to battle, test that together and really see, I'm throwing both scenarios at you: you're losing your access to the database. What's going to happen? Go, fight.” [laugh].Leo: You know, one thing that I've been mentioning to people, this is my hypothesis as to the future of chaos engineering as a component of solutions architecture. My hypothesis is that just as nowadays, if you look at any application, any service, for that application or service to be production-ready, you have a certain percentage of unit test coverage and you have a certain percentage of end-to-end coverage of testing and whatnot, and you cannot ignore and say I'm going to give you a production-ready application or production-ready system without solid testing coverage. My hypothesis is that [unintelligible 00:19:21]. And as a side note, we are now living in a world of infrastructure as code, and manifested infrastructure, and declarative infrastructure, and all sorts of cool new ways to deploy and deliver that infrastructure and workloads on top of it. My theory is that just as unit testing coverage is a requirement for any production-ready solution or application nowadays, a certain percentage of, “Chaos coverage,” quote-unquote.In other words, what percentage of the surface of your infrastructure had been exercised by chaos experiments, is going to also become a requirement for any production-ready architecture. That's is where my mind is at. I think you'll start seeing that happen in CI/CD pipelines, you're going to start seeing labels of 90% chaos coverage on Terraform repos. That's kind of the future. That I hope because I think it's going to help tremendously with reliability, and allow people to party without concern for being called back to the office in the middle of the night. It's just going to have a positive impact overall.Ana: I definitely love where that vision is going because that's definitely very much of what I've seen in the industry and the community. And with a lot of the open-source projects that we see out there, like, I got to sit in on a project called Keptn, which gets a chance to bring in a little bit more of those SRE-driven operations and try to close that loop, and auto-remediate, and all these other nice things of DevOps and cloud, but a big portion of what we're doing with Keptn is that you also get a chance to inject chaos and validate against service-level objectives, so you get to just really bring to the front, “Oh, we're looking at this metric for business-level and service-level objectives that allow for us to know that we're actually up and running and our customers are able to use us because they are the right indicators that matter to our business.” But you get to do that within CI/CD so that you throw chaos at it, you check that SLO, that gets rolled out to production, or to your next stage and then you throw more chaos at it, and it continues being completely repetitive.Leo: That's really awesome. And I think, for example, SLOs, I think that's very valuable as well. And prioritize what you want to improve based on the output of your experiments against that error budget, for example. There's limited time, there's limited engineering capacity, there's limited everything, so this is also something that you—the output, the results, the insights that you get from executing experiments throughout your delivery lifecycle as you promote, as you progress your solution through its multiple stages, also help you identify what should be prioritized because of the impact that it may have in your area budgets. Because I mean, sometimes you just need to burn budget, you know what I'm saying?So, you can actually, clearly and quantifiably understand where to focus engineering efforts towards site reliability as you introduce changes. So yeah, I think it's—and no wonder it's such a booming concept. Everybody's talking about it. I saw Gremlin just released this new certification thing. What is it, certified chaos engineer?Jason: Gremlin-certified chaos engineering practitioner.Leo: Ah, pretty cool.Jason: Yeah.Leo: I got to get me one of those. [laugh].Jason: Yeah, you should—we'll put the link in the [show notes 00:23:19], for everybody that wants to go and take that. One of the things that you've mentioned a bunch is as we talk about automation, and automating and getting chaos engineering coverage in the same way that test coverage happens, one of the things that you're involved in—and I think why you've got so much knowledge around automation—is you've been involved in the OpenGitOps Project, right?Leo: Mm-hm. Correct.Jason: Can you tell us more about that? And what does that look like now? Because I know GitOps has become this, sort of, buzzword, and I think a lot of people are starting to look into that and maybe wondering what that is.Leo: I'm co-chair of the GitOps Working Group by the CNCF, which is the working group that effectively shepherds the OpenGitOps Project. The whole idea behind the OpenGitOps Project is to come to a consensus definition of what GitOps is. And this is along the lines of—like, we were talking about DevOps, right?Like DevOps is—everybody is doing DevOps and everybody does something different. So, there is some commonality but there is not necessarily a community-agreed-upon single perspective as to what DevOps is. So, the idea behind the OpenGitOps Project and the GitOps Working Group is to basically rally the community and rally the industry towards a common opinion as to what GitOps is, eventually work towards ways to conformance and certification—so it's like you guys are doing with chaos engineering—and in an open-source community fashion. GitOps is basically a operating model for cloud-native infrastructure and applications. So, idea is that you can use the same patterns and you can use the same model to deploy and operate the underlying infrastructure as well as the workloads that are running on top of it.It's defined by four principles that might resonate as known in common for some with some caveats. So, the first principle is that your desired state, how you want your infrastructure and your workloads to look like is declarative. No, it's—you're not—there's a fundamental difference between the declarative and imperative. Imperative is you're giving instructions to reach a certain state. The current industry is just… defining the characteristics of that state, not the process by which you reached it.The current state should be immutable and should be versioned, and this is very much aligned with the whole idea of containers, which are immutable and are versioned, and the whole idea of the Gits, that if used… [unintelligible 00:26:05] if used following best practices is also immutable and versioned. So, your declared state should be versioned and immutable.it should be continuously reconciled through agents. In other words, it eliminates the human component; you are no longer executing manual jobs and you're no longer running imperative pipelines for the deployment component of your operation. You are allowing your [letting 00:26:41] agents do that for you, continuously and programmatically.And the fourth principle is, this is the only way by which you interact with the system. In other words it completely eliminates the human component from the operating model. So, for example, when I think about GitOps as a deployment mechanism, and for example, progressive delivery within the context of GitOps, I see a lot of… what's the word I'm looking for? Like, symbiosis.Jason: Yeah. Symbiosis?Leo: Yeah. Between chaos engineering, and this model of deployment. Because I think chaos engineering is also eliminating a human component; you're no longer letting humans exercise your system to find problems, you are executing those by agents, you are doing so with a declarative model, where you're declaring the attributes of the experiment and the expected outcome of that experiment, and you're defining the criteria by which you're going to abort that experiment. So, if you incorporate that model of automated, continuous validation of your solution through premeditated chaos, in a process of continuous reconciliation of your desired state, through automated deployment agents, then you have a really, really solid, reliable mechanism for the operation of cloud-native solutions.Ana: I was like, I think a lot what we've seen, I mean, especially as I sit in more CNCF stuff, is really trying to get a lot of our systems to be able to know what to do next before we need to interfere, so we don't have to wake up. So, between chaos engineering, between GitOps, between Keptn, [unintelligible 00:28:32] how is it that you can make the load of SRE and the DevOps engineer be more about making sure that things get better versus, something just broke and I need to go fix it, or I need to go talk to an engineer to go do a best practice because now those things are built into the system as a guardrail, or there's better mental models and things that are more accurate to real conditions that can happen to a system?Leo: Actually, I sidetracked. I never ended up talking more about the OpenGitOps Project and the GitOps Working Group. So, it's a community effort by the CNCF. So, it's open for contribution by everybody. You're all in the CNCF Slack, there is an OpenGitOps Slack channel there.And if you go to github.com/open-gitops, you'll be able to find ways to contribute. We are always looking to get more involvement from the community. This is also an evolving paradigm, which I think also resonates with chaos engineering.And a lot of its evolution is being driven by the use cases that are being discovered by the end-users of these technologies and the different patterns. Community involvement is very important. Industry involvement is very important. It would be fantastic and we're an open community, and I'd love to get to know more about what you're all doing with GitOps and what it means for you and how these principles apply to the challenges that your teams are running into, and the use cases that and problems spaces that you're having to deal with.Jason: I think that's a fantastic thing for our listeners to get involved in, especially as a new project that's really looking for the insight and the contribution from new members as it gets founded. As we wrap up, Leo, do you have any other projects that you want to share? How can people find you on the internet? Anything else that you want to plug?Leo: I love to meet people on these subjects that I'm very passionate about. So yes, you can find me on Twitter. I guess, it's easier to just type it, it's @murillodigital, but you'll find that in the show notes, I imagine. As well as my LinkedIn.I have to admit, I'm more of a LinkedIn person. I don't, I hope that doesn't age me or made me uncool, but I never figured out how to really work with Twitter. I'm more of a LinkedIn person, so you can find me there. I'm an organizer in the community in Costa Rica CNCF, and I run.So, for those that are Spanish speakers, I'm very much for promoting the involvement and openness of the cloud-native ecosystem to the Hispanic and Latin community. Because I think language is a barrier and I think we're coming from countries where a lot of us have struggled to basically get our head above water from lesser resources and difficult access to technology and information. But that doesn't mean that there isn't a huge amount of talent in the region. There is. And so, I run a—there's a recent initiative by the CNCF called cloud-native TV, which is we're ten shows that are streaming on Twitch.You go to cloudnative.tv, you'll see them. I run a show called Cloud Native LatinX, which is in Spanish. I invite people to talk about cloud-native technologies that are more cloud-native communities in the region.And my objective is twofold: I want to demonstrate to all Hispanics and all Latin people that they can do it, that we're all the same, doesn't matter if you don't speak the language. There is a whole bunch of people, and I am one of them that speak the language that are there, and we're there to help you learn, and support and help you push through into this community. Basically, anybody that's listening to come out and say these are actionable steps that I can take to move my career forward. So, it's every other Tuesday on cloudnative.tv, Cloud Native LatinX, if you want to hear and see more of me talking in Spanish. It's on cloudnative.tv. And the OpenGitOps Project, join in; it's open to the community. And that's me.Ana: Yes I love that shout-out to getting more folks, especially Hispanics and Latinx, be more involved in cloud and CNCF projects itself. Representation matters and folks like me and Leo come in from countries like Costa Rica, Nicaragua, we get to speak English and Spanish, we want to create more content in Spanish and let you know that you can learn chaos engineering in English and you can learn about chaos engineering in Spanish, Ingeniería de Caos. So, come on and join us. Well, thank you Leo. Muchisimas gracias por estar en el show de hoy, y gracias por estar llamando hoy desde Costa Rica, y para todos los que están oyendo hoy que también hablen español...pura vida y que se encuentren bien. Nos vemos en el próximo episodio.Leo: Muchas gracias, Ana, and thanks everybody, y pura vida para todo el mundo y ¡hagamos caos!Jason: For links to all the information mentioned, visit our website at gremlin.com/podcast. If you liked this episode, subscribe to the Break Things on Purpose podcast on Spotify, Apple Podcasts, or your favorite podcast platform. Our theme song is called, “Battle of Pogs” by Komiku, and it's available on loyaltyfreakmusic.com.

Welcome back to the RecruitingDaily Podcast! Today, we welcome Everett Harper to speak with William Tincup about improving ethnic and gender diversity in tech. Everett is CEO and co-founder of Truss, a company built with the intention to make technology responsive to our needs. Before Truss, he worked with Linden Lab as head of customer acquisition and community. He holds an MBA and M.Ed in design & technology (Standford), as well as a BSEE in Biomedical and Electrical Engineering (Duke). Truss built its foundation by helping to save Healthcare.gov, and since has worked with massive health data systems, major transportation and logistics systems and several companies with data science specializations. The company works "side by side with your team to design, build, and scale modern software that exceeds standards for speed and security."Truss are specialists in engineering methods like iterative ("agile") development and DevOps practices while coaching companies to embed sustainable approaches that make reliable, predictable production a habit.The big questions we answer today: How can we look at COVID layoffs through the lens of diversity? What new questions are candidates and recruiters asking during the pandemic? Which events have created the most force for diversity initiatives? 

After a summer of uncertainty, what are the papers saying about the new world of work and the plans of organisations? My guests picked out four news articles (two from Forbes, one from Inc. and one from LinkedIn News) to illustrate a range of trending topics – looking at the pay of those that choose to work remotely; the difficulty of sustaining an organisational culture with a home-centric workforce; the opportunity for organisations to enable people to pursue ideas and activities outside of their core employment area; and the stress experienced by millennials for whom work has a different importance and meaning as compared to those of earlier generations.We discuss the issues raised and share our views and experiences in this lively discussion. Links to the articles appear below for those that would like to read them in full.AWA Host: Karen PlumFeatured guests: Andrew Mawson, Founder & Managing Director, AWACeleste Tell, Senior Associate, AWA AWA Guest details: https://www.advanced-workplace.com/awa/about-awa/the-team/  Article links:Inc, Why Google's Plan to Cut Remote Worker Pay Is a Bad Idea https://www.inc.com/minda-zetlin/google-remote-pay-cut-calculator-facebook-twitter-employees-policy.html  Forbes, Redefining Company Culture With A Home-Centric Workforce https://www.forbes.com/sites/forbeshumanresourcescouncil/2021/08/30/redefining-company-culture-with-a-home-centric-workforce/?sh=74a81918bbbb Forbes, Are You Brave Enough To Allow For Flexibility? https://www.forbes.com/sites/forbestechcouncil/2021/08/30/are-you-brave-enough-to-allow-for-flexibility/?sh=51df82042f15 LinkedIn News, Millennials are Most Stressed About https://www.linkedin.com/feed/update/urn:li:activity:6836448001368625152/  Valve's cabal process approach: Article: https://www.gamedeveloper.com/design/the-cabal-valve-s-design-process-for-creating-i-half-life-i- Research paper: https://www.researchgate.net/publication/254943466_Get_Organized_at_Work_A_Look_Inside_the_Game_Design_Process_of_Valve_and_Linden_Lab  CONTACTS & WEBSITE details:AWA contact: Andrew Mawson amawson@advanced-workplace.com  Advanced Workplace Associates: https://www.advanced-workplace.com/      AWI contact: David Smalley  dsmalley@advanced-workplace.com Advanced Workplace Institute:  https://www.advanced-workplaWant to know more about AWA? Follow us on LinkedIn Visit our website Thanks for listening to the DNA of work podcast

Audio glitches again. They're less obvious on speakers. Hopefully we've actually fixed it this time.The director of Wonder Woman 1984 has joined the crusade to stop movies being released on streaming. She thinks they look fake. It's a good cause, but we're not sure the world is ready for this.Junk food lowers your life expectancy. Fruit is good for you. A new study has put numbers to just how good and bad some foods are for you.It's time to step into the Multiverse. Actually, not so fast, it's not a thing yet. But it will be soon, and people are really into it. And hopefully this time it won't involve insane developers killing player's meat bodies, or using it to make society even more monetised.Streaming Movies Are Fake- https://comicbook.com/dc/news/wonder-woman-director-patty-jenkins-says-streaming-service-movie-look-fake/- https://www.latimes.com/entertainment-arts/business/newsletter/2021-08-31/how-wonder-woman-1984-director-patty-jenkins-really-feels-about-streaming-movies-the-wide-shot Fact : Junk Food Lowers Your Life Expectancy- https://www.iflscience.com/health-and-medicine/one-hot-dog-knocks-36-minutes-off-your-life-study-claims/ Screw The Multiverse..There Is The Metaverse- https://www.gamesindustry.biz/articles/2021-08-20-what-is-the-metaverse-and-why-is-it-worth-so-much-money Other topics discussedDune's Theatrical Release Date Has Been Delayed in Australia- https://www.gizmodo.com.au/2021/09/dune-release-date-delayed-australia/Dune 2 is not a sure thing – but director Denis Villeneuve is optimistic- https://www.gamesradar.com/amp/dune-2-is-not-a-sure-thing-but-director-denis-villeneuve-is-optimistic/ Writers Guild of America, East (a labor union representing film and television writers as well as employees of television and radio news. The Writers Guild of America, East is affiliated with the Writers Guild of America West.)- https://en.wikipedia.org/wiki/Writers_Guild_of_America,_East Writers Guild of America West (a labor union representing film, television, radio, and new media writers. It was formed in 1954 from five organizations representing writers, including the Screen Writers Guild.)- https://en.wikipedia.org/wiki/Writers_Guild_of_America_West New Farm Cinemas (a cinema at 701 Brunswick Street, New Farm, City of Brisbane, Queensland, Australia.)- https://en.wikipedia.org/wiki/New_Farm_Cinemas 2001: A Space Odyssey (a 1968 epic science fiction film produced and directed by Stanley Kubrick. )- https://en.wikipedia.org/wiki/2001:_A_Space_Odyssey_(film) Screen Actors Guild (The Screen Actors Guild (SAG) was an American labor union which represented over 100,000 film and television principal and background performers worldwide.)- https://en.wikipedia.org/wiki/Screen_Actors_GuildIMPACT World+: a globally regionalized life cycle impact assessment method- https://link.springer.com/article/10.1007/s11367-019-01583-0 Frankfurter Würstchen (A Frankfurter (German for Frankfurt sausage) is a thin parboiled sausage made of pure pork in a casing of sheep's intestine.)- https://en.wikipedia.org/wiki/Frankfurter_W%C3%BCrstchenAn Australian 'wellness guru' says staring directly into the sun is 'one of the best forms of free medicine'- https://www.businessinsider.com/pete-evans-says-staring-into-the-sun-is-a-form-of-medicine-2018-12?r=AU&IR=T Second Life (an online virtual world, developed and owned by the San Francisco-based firm Linden Lab and launched on June 23, 2003.)- https://en.wikipedia.org/wiki/Second_Life Mastodon (software) (free and open-source software for running self-hosted social networking services. It has microblogging features similar to the Twitter service, which are offered by a large number of independently run Mastodon nodes (known as "instances"), each with its own code of conduct, terms of service, privacy options, and moderation policies.)- https://en.wikipedia.org/wiki/Mastodon_(software)How an avatar on Second Life sparked a real-life court case- https://www.theguardian.com/technology/2008/nov/25/second-life-internet Ready Player One (film) (a 2018 American science fiction adventure film based on Ernest Cline's 2011 novel of the same name. Directed by Steven Spielberg, from a screenplay by Zak Penn and Cline, it stars Tye Sheridan, Olivia Cooke, Ben Mendelsohn, Lena Waithe, T.J. Miller, Simon Pegg, and Mark Rylance.)- https://en.wikipedia.org/wiki/Ready_Player_One_(film)Fortnite Is Letting You Relive MLK's 'I Have A Dream' Speech- https://www.npr.org/2021/08/27/1031674883/fortnite-mlk-i-have-a-dream-speech-martin-luther-king Guide to roleplaying a wedding (Although weddings are not recognized by World of Warcraft in any way (one does not get any benefits), couples can still get married simply for roleplaying purposes.)- https://wowwiki-archive.fandom.com/wiki/Guide_to_roleplaying_a_wedding Dwarf Fortress ((officially called Slaves to Armok: God of Blood Chapter II: Dwarf Fortress) is a construction and management simulation and roguelike indie video game created by Bay 12 Games. Freeware and in development since 2002, its first alpha version was released in 2006 and it received attention for being a two-member project surviving solely on donations.)- https://en.wikipedia.org/wiki/Dwarf_Fortress Sword Art Online (a Japanese light novel series written by Reki Kawahara and illustrated by abec. The series takes place in the near future and focuses on protagonist Kazuto "Kirito" Kirigaya and Asuna Yuuki as they play through various virtual reality MMORPG worlds.)- https://en.wikipedia.org/wiki/Sword_Art_OnlineShout Outs 29th August 2021 – WA researchers make history with first locally-made satellite launched into space - https://www.abc.net.au/news/2021-08-29/first-wa-satellite-binar-1-launched-into-space/100415996?fbclid=IwAR0Vtn6QTsYMHFVfZOVoHY4RqMOCA2D7seRFRmAHxXibQPABSbHGjepoJbo A small group of Perth researchers have made Western Australian history, using a device not much bigger than a vegemite sandwich. The Binar-1 satellite was launched into orbit on Sunday afternoon (Perth time) aboard a SpaceX Dragon spacecraft from NASA's Kennedy Space Centre in Florida, US. The craft, which takes its name from the Noongar word for fireball, will now head to the International Space Station, where astronauts will release the satellite into low-Earth orbit. It marks the first time a WA-made satellite has been launched into space. Phil Bland, the director of Curtin University's Space Science Technology Centre, which built the device, says it won't be the last. "You're not succeeding in space unless you're flying stuff, so we are building the technology that is going to allow us to fly all the time," Mr Bland said. The Binar team are hoping to launch at least seven small spacecraft over the next two years, to prove their technology works. If it does, it could make a massive difference to the way Western Australians are able to access space. Binar researcher and PhD student Ben Hartig wrote about how important that would be for Australia. "By developing completely home-grown technology, we can avoid relying on expensive imported components, meaning the Australian space industry can stand on its own two feet while reaching for the heavens," he said.29th August 2021 – Astra Test Flight (Launch Vehicle 0006) - https://www.youtube.com/watch?v=O8Tdm797BzM&t=5612s Astra launched its fourth Rocket 3 vehicle, Rocket 3.3 (LV0006). The flight carried an instrumentation payload for the United States Space Force under the Space Test Program, and a separation of payload from the launch vehicle was not planned. Shortly after liftoff, a single engine failure caused the vehicle to drift horizontally several tens of meters sideways off the launch pad before ascending vertically. The vehicle deviated from its licensed trajectory and range safety terminated the flight at approximately T+2:28. The rocket reached a peak altitude of 50 km before crashing into the ocean downrange of the launch site. No injuries or damage to property were reported from this incident.30th August 2021 – Actor Ed Asner passes away at 91 - https://www.abc.net.au/news/2021-08-30/ed-asner-dies-aged-91-up-mary-tyler-moore-lou-grant/100417378?fbclid=IwAR2JabVjk-9-u9xa5mmjdKjjiOprn1NIXQOcpFOrNGdIA-orQN0CkGp-bSM Asner, whose diverse credits also included a key voice role in the acclaimed 2009 animated film Up, died at his home surrounded by his family, Asner was known for his liberal politics and his stint as Screen Actors Guild president in the 1980s when he criticised US involvement in Central America during the administration of a previous head of the actors' union, then-president Ronald Reagan. In a career of remarkable longevity, Asner acted into his 90s. Asner was integral to the success of the situation comedy Mary Tyler Moore, which ran on CBS from 1970 to 1977 and boasted one of the best assemblages of actors and writers in US TV history. Later in his career, Asner became a successful voice actor for animated TV shows and films and played Santa Claus in several projects, including the 2003 Will Ferrell comedy Elf. In the sentimental 2009 animated film Up, Asner provided the voice for the main character, 78-year-old Carl Fredricksen, who after the death of his beloved wife ties balloons to his house and floats off to fulfil his fantasy of exploring South America, only to find he has a youthful stowaway. The movie won an Oscar for best animated film and a nomination for best picture. Asner remained a busy actor into his 90s with appearances in such series as Dead to Me and Cobra Kai. He died of natural causes at his home in the Tarzana, Los Angeles.1st September 2021 – 15th anniversary of Idiocracy - https://en.wikipedia.org/wiki/Idiocracy The film, written by Beavis & Butthead creator Mike Judge and Tropic Thunder co-writer Etan Cohen, imagines a world 500 years into the future, when civilization has all but collapsed because humanity has become irretrievably stupid. It illustrates how this happened with a voice-of-God narrator and a comparative case study: the high IQ yuppie couple who sensibly wait and wait to have kids until they can't anymore on one side, and the trailer trash meatheads (really no other way to describe them) with the giant brood of neglected children and Maury Povich-esque sex life who keep procreating at an alarming rate on the other. The film was not screened for critics, and the distributor, 20th Century Fox, was accused of abandoning it. Despite its lack of a major theatrical release, which resulted in a mere $495,000 gross at the box office, the film received positive reviews from critics and has become a cult film. During the 2016 presidential primaries, writer Etan Cohen and others expressed opinions that the film's predictions were converging on accuracy, a sentiment repeated by director Judge during the general election. At the time, Judge also compared Republican presidential nominee Donald Trump—who later won and became President of the United States—to the film's wrestler-turned-president, Dwayne Elizondo Mountain Dew Herbert Camacho. When asked about predicting the future, he remarked, "I'm no prophet, I was off by 490 years."Remembrances31st August 1965 – E.E.Smith - https://en.wikipedia.org/wiki/E._E._Smith Edward Elmer Smith, publishing as E. E. Smith, Ph.D. and later as E. E. "Doc" Smith, was an American food engineer (specializing in doughnut and pastry mixes) and science-fiction author, best known for the Lensman and Skylark series. He is sometimes called the father of space opera. Smith's work is strongly identified with the beginnings of US pulp sf as a separate marketing genre, and did much to define its essential territory: galactic space dominated by Galactic Empires, these usually being run by humans, though Aliens appear frequently, not only as Villains; Space Opera plots, featuring Heroes and their Inventions, are the norm; Wars rage across the parsecs. But although Smith's his protagonists fit comfortably into this universe, it is the case that his greatest protagonists, the Lensmen, are also soldiers: willing employees in a higher cause. His earlier heroes may be freelance, and seem in retrospect singularly detached from the universes they dazzle, but his later heroes – like Kim Kinnison himself – advance through promotion, and rule their universes as dictators in all but name, for the cause of Good. When in 1915 Smith began to write the first novel of his Skylark series with Mrs Lee Hawkins Garby, a neighbour seconded to help with feminine matters such as dialogue, no prior models existed in popular fiction to source the combined exuberance and scale that The Skylark of Space (written 1915-1920; August-October 1928 Amazing; 1946; rev with cuts 1958) demonstrated when it finally began to appear in Amazing Stories, two years after the start of that magazine, in the same issue as Philip Nowlan's "Armageddon – 2419 A.D." (August 1928 Amazing), the story which introduced Buck Rogers in the 25th Century. It was not until he began to unveil the architectural structure of his second and definitive Series that Smith was able to demonstrate the thoroughness of his thinking about Space Opera. And it is with the Lensman series – or The History of Civilization, the over-title for the 1953-1955 limited-edition boxed reprint of the original books – that his name is most strongly and justly associated. The Lensman series inspired one of the earliest of sf WarGames, Lensman (1969). Two Japanese Anime adaptations, the film Lensman and the Television series Galactic Patrol Lensman (1984-1985), unfortunately poisoned Hollywood interest in Western versions of the saga. Smith was widely read by scientists and engineers from the 1930s into the 1970s. He was posthumously inducted into the Science Fiction Hall of Fame in 2004. He died at the age of 75 in Seaside, Oregon. Famous Birthdays 31st August 1821 – Hermann von Helmholtz - https://en.wikipedia.org/wiki/Hermann_von_Helmholtz A German physicist and physician who made significant contributions in several scientific fields. The largest German association of research institutions, the Helmholtz Association, is named after him. In physiology and psychology, he is known for his mathematics of the eye, theories of vision, ideas on the visual perception of space, color vision research, and on the sensation of tone, perception of sound, and empiricism in the physiology of perception. In physics, he is known for his theories on the conservation of energy, work in electrodynamics, chemical thermodynamics, and on a mechanical foundation of thermodynamics. As a philosopher, he is known for his philosophy of science, ideas on the relation between the laws of perception and the laws of nature, the science of aesthetics, and ideas on the civilizing power of science. His first important scientific achievement, an 1847 treatise on the conservation of energy, was written in the context of his medical studies and philosophical background. His work on energy conservation came about while studying muscle metabolism. He tried to demonstrate that no energy is lost in muscle movement, motivated by the implication that there were no vital forces necessary to move a muscle. This was a rejection of the speculative tradition of Naturphilosophie which was at that time a dominant philosophical paradigm in German physiology. In fluid dynamics, Helmholtz made several contributions, including Helmholtz's theorems for vortex dynamics in inviscid fluids. Helmholtz was a pioneer in the scientific study of human vision and audition. Inspired by psychophysics, he was interested in the relationships between measurable physical stimuli and their correspondent human perceptions. For example, the amplitude of a sound wave can be varied, causing the sound to appear louder or softer, but a linear step in sound pressure amplitude does not result in a linear step in perceived loudness. The physical sound needs to be increased exponentially in order for equal steps to seem linear, a fact that is used in current electronic devices to control volume. Helmholtz paved the way in experimental studies on the relationship between the physical energy (physics) and its appreciation (psychology), with the goal in mind to develop "psychophysical laws." Helmholtz studied the phenomena of electrical oscillations from 1869 to 1871, and in a lecture delivered to the Naturhistorisch-medizinischen Vereins zu Heidelberg (Natural History and Medical Association of Heidelberg) on 30 April 1869, titled On Electrical Oscillations he indicated that the perceptible damped electrical oscillations in a coil joined up with a Leyden jar were about 1/50th of a second in duration. He became interested in electromagnetism, and the Helmholtz equation is named for him. Although he did not make major contributions to this field, his student Heinrich Rudolf Hertz became famous as the first to demonstrate electromagnetic radiation. He was born in Potsdam, Province of Brandenburg, Kingdom of Prussia, German Confederation.Events of Interest31st August 1422 – King Henry V of England dies of dysentery while in France. His son, Henry VI becomes King of England at the age of nine months. - https://en.wikipedia.org/wiki/Henry_VI_of_England#Child_king He succeeded to the throne as King of England at the age of nine months on 1 September 1422, the day after his father's death; he remains the youngest person ever to succeed to the English throne. On 21 October 1422, in accordance with the Treaty of Troyes of 1420, he became titular King of France upon his grandfather Charles VI's death. His mother, the 20-year-old Catherine of Valois, was viewed with considerable suspicion by English nobles as Charles VI's daughter. She was prevented from playing a full role in her son's upbringing. In reaction to the coronation of Charles VII of France in Reims Cathedral on 17 July 1429, Henry was soon crowned King of England at Westminster Abbey on 6 November 1429, aged 7, followed by his own coronation as King of France at Notre Dame de Paris on 16 December 1431, aged 10. He was the only English king to be crowned king in both England and France. It was shortly after his crowning ceremony at Merton Priory on All Saints' Day, 1 November 1437, shortly before his 16th birthday, that he obtained some measure of independent authority. This was confirmed on 13 November 1437, but his growing willingness to involve himself in administration had already become apparent in 1434, when the place named on writs temporarily changed from Westminster (where the Privy Council met) to Cirencester (where the King resided). He finally assumed full royal powers when he came of age at the end of the year 1437, when he turned sixteen years old. Henry's assumption of full royal powers occurred during the Great Bullion Famine and the beginning of the Great Slump in England. 31st August 1956 – The Forbidden Planet landed in Ireland - https://www.imdb.com/title/tt0049223/ On this day in 1956 (in Ireland), Forbidden Planet arrived in Earth's theaters. Here's the plot summary: "When Adams and his crew are sent to investigate the silence from a planet inhabited by scientists, he finds all but two have died. Dr. Morbius and his daughter Altaira have somehow survived a hideous monster which roams the planet. Unknown to Adams, Morbius has made a discovery, and has no intention of sharing it (or his daughter!) with anyone."First mainstream film to have the music performed entirely by electronic instruments.The famous poster for the film shows a menacing robot carrying a struggling pretty girl - a staple of "monster movie" posters from the 1950's. In fact, no such scene occurs in the film itself and the robot portrayed in the poster is of course actually the very likeable Robby the Robot.Robert Kinoshita, who is credited with building Robby the Robot, was also Art Director for the TV series Lost in Space (1965). Many of the "Lost in Space" robot's features are similar to Robby's: glass "head" with animated elements; rotating antenna "ears" (although the "Lost" robot's ears rarely moved after the pilot episode); flashing light "mouth"; chest panel with more animated elements. For that matter, much of the layout of "Forbidden Planet"'s spaceship is mirrored by "Lost"'s Jupiter 2: saucer shape; integral landing gear/entry stairs; lower external dome with animated lights; central, plexi-domed navigation station; vertical hibernacula arranged along perimeter. In addition, Robby and the "Lost" robot had a couple of "family reunions" in two "Lost in Space" episodes: Lost in Space: War of the Robots (1966) and Lost in Space: Condemned of Space (1967).Robby the Robot was originally operated by stuntman/actor Frankie Darro. He was fired during filming after almost falling over while in the expensive prop, following a five-martini lunch.With the death of James Drury (Crewman Strong) on April 6, 2020, Earl Holliman (Cookie) is the last surviving member of the cast.According to Anne Francis, Walter Pidgeon loved to disrupt takes by reciting dirty limericks in the middle of his dialogue.IntroArtist – Goblins from MarsSong Title – Super Mario - Overworld Theme (GFM Trap Remix)Song Link - https://www.youtube.com/watch?v=-GNMe6kF0j0&index=4&list=PLHmTsVREU3Ar1AJWkimkl6Pux3R5PB-QJFollow us on Facebook- Page - https://www.facebook.com/NerdsAmalgamated/- Group - https://www.facebook.com/groups/440485136816406/Twitter - https://twitter.com/NAmalgamatedSpotify - https://open.spotify.com/show/6Nux69rftdBeeEXwD8GXrSiTunes - https://itunes.apple.com/au/podcast/top-shelf-nerds/id1347661094Instagram - https://www.instagram.com/nerds_amalgamated/Email - Nerds.Amalgamated@gmail.comSupport via Podhero- https://podhero.com/podcast/449127/nerds-amalgamated See acast.com/privacy for privacy and opt-out information.

Hunter's BioHunter Walk is a co-founder and Partner at Homebrew, which is an early-stage venture capital firm based in the Bay Area.  Before Homebrew, I led consumer product management at YouTube, starting when it was acquired by Google. I originally joined Google in 2003, managing product and sales efforts for AdSense, Google‘s contextual advertising business. My first job in Silicon Valley was as the founding product and marketing guy at Linden Lab. Before graduate school, I was a management consultant and also spent a year at Late Night with Conan O‘ Brien. My parents are proud of my BA in History from Vassar and MBA from Stanford University.★ Support this podcast ★

Charity Majors (https://twitter.com/mipsytipsy) is the co-founder and CTO of Honeycomb.io. Before this she worked at Facebook, Parse and Linden Lab on infrastructure and developer tools, and always seemed to wind up running the databases. She is the co-author of Database Reliability Engineering book and also has an amazing blog at charity.wtf. We love the content in her blogs and have learned a lot from them. We had a lot of fun speaking with Charity in this lively conversation! We learned about her journey from being an engineer to co-founding Honeycomb, what it was like being on-call when she was only 17, and staying calm during production incidents. We talked about various production outages throughout the episode and our favorite involved driving to a datacenter to flip a DB switch. Charity also shares what it takes to build an awesome engineering culture, the engineer/manager pendulum, and qualities Charity looks for when hiring senior engineers.

Hunter is a partner at Homebrew, a seed stage venture fund. Before Homebrew, he led consumer product management at YouTube, starting when it was acquired by Google. Hunter originally joined Google in 2003, managing product and sales efforts for AdSense. Prior to Google, he was a founding member of the product and marketing team at Linden Lab, the creators of the online virtual world, Second Life. [0:10] - Hunter's story [2:44] - Thoughts on the ongoing exodus from major cities [6:51] - The future balance of hybrid work models [10:04] - Online serendipity [15:52] - Hunter's early career experiences [19:28] - Hunter's role in YouTube's growth [22:25] - The Homebrew origin story [23:43] - Investing in problem-solving founders -- Thank you for listening to Pod of Jake! All shares and reviews are sincerely appreciated! LINKS: Twitter: @blogofjake Website: podofjake.com Blog: blogofjake.com Email: jake@blogofjake.com Call: superpeer.com/jake Support: patreon.com/blogofjake Bitcoin: 3ESGQxrJZmGqd2SifqCUiHPvah1uWtN1Zd Ethereum: blogofjake.eth 0xF89aCC1f8c4FeEAc372997006BfE7c0fdD99F80c Bitcoin Cash: qznma8vxf8kjn4v9phsfkhzd0559gm7yfsx0gkl4sf

The first Late Night Ramble of 2021 welcomed Rod Humble to talk about his experiences of supporting Aston Villa in the US over the last 30 years. Rod is well known for his work in the gaming industry as the former CEO of Second Life creator Linden Lab and Head of EA Play where he was the man responsible for the Sims franchise of games. He is now at Paradox Interactive where he heads up their studio, Paradox Tectonic.  Rod discussed his Villa history including keeping up to date with the team in the US in the 90s, his love for Tony Daley and finally being able to speak loudly about his team in San Fransisco.  We also previewed the upcoming FA Cup tie against Liverpool and Rod gave his thoughts on how he would approach the game. Finally, it wouldn't have been a Late Night Ramble without another edition of Didier Six! Don't forget to check out our last Late Night Ramble of 2020 - our interview with Dwight Yorke. Available on your chosen podcast platform or on YouTube. Guest: Rod Humble Host: Omar Twitter: @villapodcast Instagram: @thevillatalks Facebook: @villapodcast Please subscribe and follow. UTV!

Hunter Walk is a founding Partner at Homebrew.Homebrew is a Seed stage venture firm providing capital and assistance to entrepreneurs who are building the companies that they envision within the Bottom Up Economy. Some notable investments are Plaid, Cruise, ShieldAI, and theSkimm.Prior he led customer product management at YouTube and was on the founding team at Linden Lab, the creators of Second Life.

Hunter Walk (@hunterwalk) is Co-founder & Partner at Homebrew, a seed-stage venture firm he founded in 2013 with Satya Patel. Homebrew has invested in the likes of Plaid, Gusto, Chime, Bowery Farming, Stir, Finix Payments, Honor, Lumi, Tia, theSkimm, Winnie, and many more (see full portfolio). Prior to founding Homebrew, Hunter led consumer product management at YouTube, spent time on the product and marketing team at Linden Lab, and worked in management consulting at Deloitte. In this episode, Hunter and The Takeoff's Michael Spiro discuss: Founding Homebrew with Satya Patel How Homebrew adds value to portfolio founders Changes to the seed investing landscape since Homebrew started in 2013 Optimizing for processes and learning early on, not just hitting milestones Consulting at Deloitte out of school Why you should focus on learning early in your career Advice for aspiring VCs & more You can find Hunter's blog at https://hunterwalk.com/about/. He's on Twitter @hunterwalk (I highly recommend following him if you aren't already!). If you dig what we're doing with The Takeoff, go ahead and subscribe to our newsletter https://thetakeoff.substack.com/ and follow us on Twitter @_TheTakeoff. We're a student-run podcast & newsletter hoping to become the go-to spot for students and young professionals looking to learn more about startups, tech, venture capital, and more. Items reference in the episode: Mark Suster's blog post (Upfront Ventures): https://bothsidesofthetable.com/is-it-time-for-you-to-earn-or-to-learn-34270acd2f4 Influence by Robert Cialdini: https://www.amazon.com/Influence-Psychology-Persuasion-Robert-Cialdini/dp/006124189X (Apologies for the suboptimal audio in the first few minutes of the episode. I was recording out of my college apartment and a bunch of background noises popped up. We did our best to get rid of them all, but, unfortunately, we're not audio engineers)

Have you ever wished that you could verbally tell the story of a photo and connect it to the image?  Suppose you could do that through an app or a phone call.  And it was FREE.  There is a company that offers a way to save those photo stories by putting pictures and words together. It's pretty amazing.   It's called Storyglory.meOn a visit home to Minneapolis one holiday, my guest  found a box of old photos in the closet, spread them out on the kitchen table, and started scanning them with his phone. The process inspired him to found Storyglory.meStoryglory.me helps families capture these emotional moments present in photographs in an elegant, heartfelt way with voice, photos, and video. Built from the ground up with privacy in mind, Storyglory enables family storytelling and sharing that would be uncomfortable on public and advertising-supported social media. Brad Nemer (CEO) founded the company in 2015 in San Francisco and is joined in leadership by co-founder Graham Myhre (CTO).Related Episodes:Episode 82: Every Thing Tells a StoryEpisode 77: Interviewing Relatives: A Conversation with Personal Biographer Francie KingLinks:Storyglory.meSign up for my newsletter.Watch my YouTube Channel.Like the Photo Detective Facebook Page so you get notified of my Facebook Live videos.Need help organizing your photos? Check out the Essential Photo Organizing Video Course.Need help identifying family photos? Check out the Identifying Family Photographs Online Course.Have a photo you need help identifying? Sign up for photo consultation.About My Guest:Brad is the founder and CEO of Storyglory. He has led product design and management at large companies such as Motorola, CASIO, and Asurion (mobile insurance provider for the world's largest carriers), as well as at startups such as Wikia and Linden Lab. Brad earned his undergraduate degree in Political Science at Washington University in Saint Louis, and pioneered the industry's first MBA + Design dual masters program at the Illinois Institute of Technology's Institute of Design. Brad has taught graduate-level design and business at the Institute of Design, and at the Stanford d.school.About Maureen Taylor:Maureen is a frequent keynote speaker on photo identification, photograph preservation, and family history at historical and genealogical societies, museums, conferences, libraries, and other organizations across the U.S., London and Canada.  She's the author of several books and hundreds of articles and her television appearances include The View and The Today Show (where she researched and presented a complete family tree for host Meredith Vieira).  She's been featured in The Wall Street Journal, Better Homes and Gardens, The Boston Globe, Martha Stewart Living, Germany's top newspaper Der Spiegel, American Spirit, and The New York Times. Maureen was recently a spokesperson and photograph expert for MyHeritage.com, an internationally known family history website and also writes guidebooks, scholarly articles and online columns for such media as Smithsonian.com. Learn more at Maureentaylor.com Did you enjoy this episode? Please leave a review on Apple Podcasts.

Welcome to another episode of Develomentor. Today's guest is Charity MajorsCharity Majors is a former systems engineer and manager at Facebook, Parse, and Linden Lab. She is also the co-author of Database Reliability Engineering. Charity is the co-founder and CTO of honeycomb.io, a company dedicated to building production engineering and observability products“With distributed systems, you don’t care about the health of the system, you care about the health of the event or the slice.”If you are enjoying our content, click here to support us!Episode Summary“Our [systems engineers] expertise is around everything from performance and optimization to capacity, projections and provisioning.”“Ops teams have a dark sense of humor. In my experience, they also tend to have the most cohesive teams out of all engineering teams. And i think its because they walk through the fire together.”“I think that new managers need to commit to it [management] for about 2 years. That’s about how long it takes for your brain to rewire itself and learn how to build that inner voice that you can trust that tells you if you’re doing well or not.”“I wanted to write go code for 2 years straight. That’s all I wanted to do after Facebook. Just heads down, write software!”“Looking at the way we build software now its so painful and its so inefficient and it doesn’t have to be. The biggest obstacle I see between us as an industry and a better way is that we’ve come to believe that this is just how it is.”—Charity Majors“Basically in a large site with tens of thousands of servers, every day something is breaking.”—Grant IngersollAdditional ResourcesEp. 4 Goldman Sachs Saved My Tech Career, with Camille FournierWhat is observability and cardinality? https://thenewstack.io/observability-a-3-year-retrospective/Learn more about honeycomb.io – https://www.honeycomb.io/Check out honeycomb.io blog – https://www.honeycomb.io/blog/Read Charity’s blog – charity.wtfYou can find more resources in the show notesTo learn more about our podcast go to https://develomentor.com/To listen to previous episodes go to https://develomentor.com/blog/CONNECT WITH CHARITY MAJORSTwitterLinkedInFOLLOW DEVELOMENTORTwitter: @develomentorCONNECT WITH GRANT INGERSOLLLinkedInTwitter

Vinny Catalano, Chief Investment Officer at Redmount Capital Partners, discusses the warning signs investors need to pay attention to and those they should ignore. Ebbe Altberg, CEO at Linden Lab, talks about advances in virtual reality.  Hosts: Lisa Abramowicz and Paul Sweeney. Producer: Paul Brennan.   

Vinny Catalano, Chief Investment Officer at Redmount Capital Partners, discusses the warning signs investors need to pay attention to and those they should ignore. Ebbe Altberg, CEO at Linden Lab, talks about advances in virtual reality.  Hosts: Lisa Abramowicz and Paul Sweeney. Producer: Paul Brennan.    Learn more about your ad-choices at https://www.iheartpodcastnetwork.com

Charity first took us through the pain of being a CEO and explained us why she chose to focus on tech again after a while. She then explained how she felt into code instrumentalisation during her time at Parse and how this became her idea for Honeycomb.io. We then went back to her early years, how she felt into IT, SysAdministration and ended up working in the Silicon Valley. We talked about mentorship, learning and sharing. We dwelved on the public speaking skills as a leadership skill before talking about the private meetups that Charity organises. Finally, we talked about the technical-leader role and the necessity to move back and forth from management to tech to hone both skills and bring the two worlds together.Charity Majors is an ops engineer and accidental CEO at honeycomb.io. Before this she worked at Parse, Facebook, Linden Lab on operations and developer tools... and she always seems to wind up running the databases. Co-author of O'Reilly's 'database reliability engineering' book, she loves free speech, free software and single malt scotch.Here are the links of the show:https://twitter.com/mipsytipsyhttps://charity.wtfhttps://www.honeycomb.io/play/https://charity.wtf/2018/08/24/how-to-run-a-tech-leadership-skill-sharehttps://github.com/charity/tech-leads-skill-sharehttps://www.lifehack.org/articles/featured/how-to-start-and-run-a-mastermind-group.htmlCreditsMusic Aye by Yung Kartz is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License.Your hostSoftware Developer‘s Journey is hosted and produced by Timothée (Tim) Bourguignon, a crazy frenchman living in Germany who dedicated his life to helping others learn & grow. More about him at timbourguignon.fr.Want to be next?Do you know anyone who should be on the podcast? Do you want to be next? Drop me a line: info@devjourney.info or via Twitter @timothep.Gift the podcast a ratingPlease do me and your fellow listeners a favor by spreading the good word about this podcast. And please leave a rating (excellent of course) on the major podcasting platforms, this is the best way to increase the visibility of the podcast:Apple PodcastsStitcherGoogle PlayThanks!Support the show (http://bit.ly/2yBfySB)

GUEST BIO: Charity is CEO at honeycomb.io.  She is a former systems engineer and manager at Facebook, Parse and Linden Lab always seeming to end up responsible for databases.  Charity is also the co-author of O’Reilly’s Database Reliability Engineering and a regular conference speaker. EPISODE DESCRIPTION: Phil’s guest on today’s show is Charity Majors. She started her career working as a systems engineer and manager for Linden Lab then Shopkick and Cloudmark Inc. Charity was the Infrastructure Tech Lead at Parse when they were taken over by Facebook. At that point, she became a Production Engineering Manager at Facebook. In 2016, she co-founded honeycomb.io. Today, she is CEO of this multi-node debugging tool provider. Charity is also the co-author of O’Reilly’s Database Reliability Engineering. She is also a prolific and well-known conference speaker. KEY TAKEAWAYS: (1.02) – So Charity, can I ask you to expand on that brief intro and tell us a little bit more about yourself? Charity explains that she is a classical piano performance major dropout. She grew up without a computer. But, she ended up spending a lot of time in the computer lab while at university because she had a crush on a boy. It was then that she realized that an IT career was well paid while most music majors did not make a lot of money. Charity has worked in Silicon Valley since she was 17. She built her career primarily by building the first incarnation of infrastructure for systems that are just gaining traction. When she gets bored she moves on and finds something else that is fresh and new to get to grips with. (2.07) – It sounds to me like your passion is to be at the beginning of the start-up. Charity describes herself as the person who comes in and makes everything regular and boring. She enjoys having some chaos to tame, which is why she likes being an early adopter. (2.36) – Can you please share a unique career tip with the I.T. career audience? Charity’s advice is not to get fixated on following a traditional hierarchical career climbing path. Becoming a manager is not the only way to be successful in the IT field. If you want to simply carry on building things and progressively working on bigger and more complex projects, do that. Not everyone enjoys management. If you are one of those people, don’t let yourself be forced along that career path. Progressing along a technical route is just as valid as climbing the management ladder. (4.22) Phil agrees and comments that, in the past, climbing the management ladder was the only way to be seen as successful. But, that is starting to change with the technical path being recognized, as well. Charity agrees, but she thinks everyone needs to play a role in making sure both paths are valued. For example, when someone becomes a manager congratulate them on their career change instead of their promotion. Over the years, Charity has noticed that the most successful managers are those that see themselves as being in a supportive position rather than a dominating one. (5.24) – Phil says that is interesting given that you are now a CEO yourself. But, it sounds like you prefer to be hands on. Charity agrees that is true, up to a point. But, she does not spend as much time as she would like sat at a terminal doing stuff. This is because Charity deliberately took a step back to make sure she fulfils her role in full. When she was managing engineers, she was close enough to the code to be able to work productively alongside them. Now she is at the point where she is managing the managers she is just too far removed to carry on coding as well as managing. If she were to carry on doing that it would just be too disruptive for everyone. At the point she is at, straddling two different worlds rarely works. (6.49) – Can you share with us your worst career moment? And what you learned from that experience. Charity’s worst moment came when Parse was acquired by Facebook. The announcement was made at an all-hands meeting where she burst into tears. Other members of the team did the same or greeted the news with stony silence. Everyone was in shock, nobody had seen it coming. Charity realized immediately that working for Facebook would change her life drastically. For example, her walk to work was about to become a 3 to 4-hour commute some days. Plus, at the time, she was not a big fan of Facebook and the way they worked. She nearly quit straightaway, but stuck it out and was able to buy herself a house. (8.44) - In terms of what you learned from that, is there anything you would do differently, now? Or do you have a different perspective on things? That situation did have a big effect on her. For example, she and Christina now run honeycomb with a lot more transparency. What happened at Parse came as a huge shock to everyone. There was no time to adjust to or prepare for this massive change. After that experience here and Christina decided to take the opposite approach. They are as open as possible. To date, they have twice considered acquisitions. On both occasions they told everyone what was going on. However, taking that approach does make things a little harder for their workforce. It means they are fully aware of the companies up and downs. (10.37) – What has been your best career moment? Charity is quite shy and introverted. So, public speaking is not something that comes naturally to her. In fact, she made a complete hash of her first important talk. She was really disgusted with herself and could not wait to get out of there. However, at the same time, she was determined to conquer her fear and become a good speaker. So, she accepted every single invitation she got and actively sought out opportunities. In addition, she went to her doctor and got a beta blocker prescription, so she could control the shaking. The fear was still there, but the prescription meant that she could physically deliver the speech. Within a couple of years, she did not need the pills. A couple of years later, she was able to improvise, deliver an ad hoc speech and feel fairly comfortable while doing so. She is, understandably, very proud of that fact. Conquering this fear and learning to have the confidence to speak in an ad hoc way has helped her career in several ways. Having more confidence and better communication and presentation skills is especially helpful in her current role as CEO. (14.02) – How often do you speak publicly now? Charity says more or less every week. When Honeycomb was first founded, she spent nearly 2 years giving talks and promoting the firm. Basically, she was the marketing team. (14.24) – Can you tell us what excites you about the future of the IT industry and careers? Charity is excited that when it comes to treating employees as people the industry is starting to get things together. For the tech sector, this is a golden age of opportunity. There are more jobs than people. So, there is no need to suffer and stay somewhere that does not reward their people. If you do not respect your employer or like the culture, you don’t have to stay in that job. Finally, the industry is waking up to the fact that they need to be better at management and learning what makes people thrive in the workplace. For example, the days of the whiteboard coding interview are pretty much over. This high-pressure interview technique that has always been despised, so getting rid of it is a good thing. This is just one sign that the IT industry is moving in the right direction, management wise. Making these changes is far more important than the technical transformation we are also going through. The distributed team culture is great too. It is enabling people from anywhere to work together. This change means that parents, carers and people who are neurologically A-typical can all now access the workplace. (16.42) – What drew you to a career in IT? Charity explains that the money was a big draw, in part, because she grew up dirt poor. But, she also loved spending time at the university, so was motivated to study hard. She spent night after night scripting things and reading people’s bash history, teaching herself how to do Unix and loved it. (17.16) – What is the best career advice you have ever received? Charity was once told to “save money”. It was excellent advice because it means she has the security to be able to walk away from something, at any moment if she needs to. (17.37) – If you were to begin your IT career again, right now, what would you do? Charity says she would go back and get a CS degree. She would have also focused on here software engineering skills a lot more, from the beginning of her career. She thinks if she had been lucky enough to have a good manager she would have been encouraged to develop those skills early on. In fact, you could add finding a good manager to the list of things she would have done differently. She wishes she had worked for someone who has a track record for shepherding junior engineers to a senior level. (18.39) – What are you currently focusing on in your career? Right now Charity’s main focus is making sure honeycomb survives. She is working at ensuring that customers get the right product, so the money keeps coming in. As well as making sure that they gather feedback and act on it. (19.01) – What is the number one non-technical skill that has helped you the most in your IT career? Definitely public speaking, but, before that, it was writing. She relied on that skill heavily to ensure that she could communicate effectively. (19.35) – Phil asks Charity to share a final piece of career advice with the audience. If you come across something that is difficult, lean into the pain and learn how to get past it. But, be careful not to carry on pushing yourself for too long. If things are not changing and you are not making progress, you need to stop leaning into the pain. Carrying on pushing will wear you down and could lead to burn-out. BEST MOMENTS: (2.36) CHARITY– "I need a certain amount of chaos to tame." (6.26) CHARITY– "You need your full creative brain to be engaged in learning what is hard and new" (14.48) CHARITY– "For people who work in, or adjacent to IT, there's no excuse for suffering. There's so much opportunity out there." (15.09) CHARITY– "If you don't respect your employer, and don't think they're investing in the right, cultural changes and choices, don't stay," (19.20) CHARITY– "Just be good at communicating in some form"

In today's episode we talk to Thomas about what a game is and how a well-designed one balances constraints and unpredictabilities. We cover what relationships people build in and around games and how it (often) outstrips the designers' expectations of them; his experience with Linden Lab and how Second Life was designed not as a game but as a platform for game making; player governance as a legitimate component of an online space; the connection between trust, ethics, and governance and why it's necessary for game companies to participate in digital, public spaces. We talk about identity and building inclusive avatars and the asymmetry between players and game makers. Lastly we talk about chance, patterns and open ended-ness in games. Mentioned in Podcast: Making Virtual Worlds: Linden Lab and Second Life (2009, Cornell University Press) -Addiction by Design: Machine Gambling in Las Vegas (2014, Princeton University Press) Emile Durkheim -The Invention of Tradition (2014, Cambridge University Press) CCP Games My Tiny Life: Crime and Passion in a Virtual World (1999, Henry Holt and Co., Inc. New York, NY, USA) and free download here Center for 21st Century Studies Serious_Play, Twitch.tv channel Coin-Operated Americans, Rebooting boyhood at the video game arcade ( 2015, Minnesota University Press) An exploratory model of play Thomas's work: Malaby, T. M. (2012). Digital Gaming, Game Design, and its Precursors. Digital Anthropology, 288-305. Oxford: Berg. Malaby, T. M. (2011). These Great Urbanist Games: New Babylon and Second Life (reprint). World Making: Media, Art, and the Politics of the Global. Rutgers University Press. Malaby, T. M. (2009, January (1st Quarter/Winter)). Anthropology and Play: The Contours of Playful Experience. New Literary History, 40(1), 205-218. Malaby, T. M. (2007). Beyond Play: A New Approach to Games. Games & Culture, 2(2), 95-113. Malaby, T. M. (2003). Gambling Life: Dealing in Contingency in a Greek City. University of Illinois Press. Social media or other links: https://thomasmalaby.com https://uwm.edu/anthropology/people/malaby-thomas-m/