Podcasts about backend

Andrew is the Headmaster at Dune Analytics. We talk the modular stack ‒ Andrew gives an accessible overview of account abstraction and intents, the potential for intents as protocol moats, where censorship and centralization might become a risk, and what the future of interacting onchain might look like. - - (00:00) Intro (02:07) Modular Stack (04:00) What is account abstraction? (08:28) What are intents? (14:00) Future of Intents (21:30) Are intents centralized? (24:30) Intents and censorship (29:00) Why is everyone sick of intents? (31:20) Intents as Protocol Moats (35:36) Front-ends as Distribution (43:32) Front-end Moats (45:03) The Back-End of the Modular Stack (47:15) Wrapping Up - - Follow Andrew: https://twitter.com/andrewhong5297 Follow Chase: https://twitter.com/chaserchapman Follow On the Other Side: https://twitter.com/ontheOSpod Subscribe on YouTube: https://bit.ly/3pJInKm Subscribe on Apple: https://apple.co/3M7wHbP Subscribe on Spotify: https://spoti.fi/3pMRbiM - -  Disclaimer: Nothing said on On The Other Side is a recommendation to buy or sell securities or tokens. This podcast is for informational purposes only, and any views expressed by anyone on the show are solely our opinions, not financial advice. Chase and our guests may hold positions in the companies, funds, or projects discussed. 

The Parasite Streak Continues. This is Kim's husband. He's a PODCASTER! I don't like Jalapeno and Oyster beeeeeeeeeeeeeeeeeeeer! Wreakin' the CVS Bathroom. PAN AM: Pansexual Amateursexual. Put That In Your Chicken And Roast It! There's Nothing West of Seattle. Back End. No Barf. Dog Bit My Crotch and I Liked it. Beer Makes People Happy. A Big Gulp Of Beer. Bombdiggity. A complete backend operation. We invented podcasting, dammit! Copyright law is messed up with Stephen and more on this episode of The Morning Stream. Hosted on Acast. See acast.com/privacy for more information.

This week, we're joined by Ron Perris, a Security Engineer at Reddit and software security enthusiast. Together, we dive into best practices and common pitfalls, covering topics from dangerous URLs to JSON injection attacks. Tune in for an educational conversation, and don't forget to bring your notebooks!

In this podcast episode, Kiri delves into the unique aspects of Walmart's marketplace and why simply copying and pasting content from Amazon won't yield meaningful results.  She explores Walmart's Listing Content score and its impact on visibility, sales, and conversion. Learn why increasing the quality score from 70% to 90% can lead to a 13% increase in conversion and how to optimize your listing content for maximum success on Walmart. Kiri also discusses the differences in the content breakdown between Walmart and Amazon, along with the recent changes implemented by Walmart. Tune in as we unravel the intricacies of the Walmart algorithm and why it's worth considering Walmart.com as a channel for ecommerce growth. Whether you're a brand looking to expand your online presence or a seller seeking a comprehensive understanding of the Walmart marketplace, this episode is packed with valuable insights to help you achieve your goals. So sit back, relax, and let's dive into the fascinating world of Walmart and its unique approach to ecommerce. In today's episode, Kiri talks about: Walmart vs. Amazon - the importance of understanding the differences for ecommerce growth  Walmart's Listing Content Score and Quality Score Walmart's Content Optimization and Algorithm Optimizing Content and Ad Strategy Walmart's Attractiveness for Ecommerce Growth Video Content on Walmart.com Importance of Establishing a Presence on Amazon Walmart's Third-Party Marketplace and Attribution Content Quality Score and its Components Obtaining Product Reviews Impact of Quality Score on Conversion Rate and Sales Importance of a High-Quality Score on Walmart Tips for Optimizing Content on Walmart

Hey there, CEOs! Dive into my conversation with Becca Mai, a business strategist and wedding planner, as she offers tangible tips to streamline your business backend. From organizing your inbox and cloud storage to the importance of SOPs, Becca breaks down strategies to make your business more efficient and profitable. Don't miss out on these actionable insights that can keep your digital world from looking like an episode of TLC's Hoarders. Let's build a better more profitable wedding industry together! =========================EPISODE SHOW NOTES BLOG: www.brandeegaar.com/204=========================JOIN THE WEDDING PRO CEO ACCELERATOR!!!Transform From Overwhelmed Business Owner to Confident CEO:https://brandeegaar.com/accelerator=========================SUPPORT THE PODCAST! LEAVE A REVIEW HERE: https://ratethispodcast.com/swd=========================Click to Join my FREE Training: How to Double Your Wedding Business Revenue (even in a down market) Join the Wedding Pro CEO Accelerator!!Support the show

Love it or hate it, TypeScript is here to stay for the foreseeable future. But, what happens when widely adopted packages go completely Type free or remove TypeScript in favor of JS with type annotations? Join us to unpack these recent events with Rich Harris, creator of Svelte, as he walks us through the nuanced decision his team made for the Svelte project, and ofc, lots of laughs along the way.

Jerod & the gang discuss the news (Astro 3.0, Vercel + Astro, Python in Excel) then play eight crazy rounds of HeadLIES! Headline or headLIE? You decide…

Happy game week! Finally, the NFL season is here and it is just days away from kicking off. We attempt to talk Packers but are, of course, derailed by some of Chewy's thoughts which leads to a show poll. What kind of road trip do you like to take? Jason Wilde joins to fun/nonsense. Is Eastern Michigan the bad guy for not just giving a player a scholarship and instead allowing another player to give theirs up? Dr. Chewy makes some appearances.

Mark Erikson (web dev professor/historian, OSS Maintainer & engineer at Replay) joins us to talk about the shift from CommonJS to ESM. We discuss the history of module patterns in JS and the grueling effort to push the world's biggest developer ecosystem forward. Get ready to go to school kids, this one's deep!

Back end of bullpen trending up!  To learn more about listener data and our privacy practices visit: https://www.audacyinc.com/privacy-policy Learn more about your ad choices. Visit https://podcastchoices.com/adchoices

What is a back-end developer? What do back-end developers do? Do they just write services? How do I become a back-end developer? These are the questions we will answer in today's episode of Dev Questions.Website: https://www.iamtimcorey.com/ Patreon: https://www.patreon.com/IAmTimCorey Ask Your Question: https://suggestions.iamtimcorey.com/ Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Serverless backend platforms are cloud services that simplify the process of building a backend. These platforms are growing rapidly in popularity because they can greatly accelerate application development, and improve the developer experience. Convex is a real-time backend platform that uses 100% TypeScript and is designed with reactive UI frameworks in mind. The team behind The post Building a Full Cloud Backend with James Cowling appeared first on Software Engineering Daily.

Serverless backend platforms are cloud services that simplify the process of building a backend. These platforms are growing rapidly in popularity because they can greatly accelerate application development, and improve the developer experience. Convex is a real-time backend platform that uses 100% TypeScript and is designed with reactive UI frameworks in mind. The team behind The post Building a Full Cloud Backend with James Cowling appeared first on Software Engineering Daily.

Serverless backend platforms are cloud services that simplify the process of building a backend. These platforms are growing rapidly in popularity because they can greatly accelerate application development, and improve the developer experience. Convex is a real-time backend platform that uses 100% TypeScript and is designed with reactive UI frameworks in mind. The team behind The post Building a Full Cloud Backend with James Cowling appeared first on Software Engineering Daily.

Hoje os nossos convidados Hugo e Zan se juntam juntam com o Willian pra falar sobre o projeto Rinha de Backend. Qual é a melhor linguagem? Como funciona? Isso e outras perguntas serão respondidas nesse episódio imperdível

Nick celebrates a decade of writing everyone's favorite language with guest Josh Goldberg, who contributes to TypeScript, maintains typescript-eslint, and is an all-around great person! Jerod is also here to join the celebration, but let's keep that a secret from him!

Tip Of The Week Secure your horses Rural Crime In The U.S. https://www.yahoo.com/news/two-fillies-were-stolen-pasture-184400111.html https://www.wtxl.com/someone-s-chopping-the-tails-off-horses-in-colorado https://jcpost.com/posts/dbd47668-cfbd-4897-b164-eadea856dfe1 Across The Pond, Down Under And Up Above https://www.kent.police.uk/news/kent/latest/policing-news/burglar-who-stole-from-farms-across-kent-jailed/ https://uk.sports.yahoo.com/news/sheffield-horse-theft-mum-offering-053652232.html https://www.farmersguardian.com/news/4121724/police Africa https://ridgetimes.co.za/325501/stock-theft-on-rise-in-embalenhle/ https://theconversation.com/bandits-in-nigeria-how-protection-payments-to-militias-escalate-conflict-in-the-north-west-211224 Chalk One Up For The Good Guys https://www.newsbreak.com/miami-fl/3115971595777-stolen-farm-animals-discovered-crammed-into-back-of-van https://www.agdaily.com/news/human-trafficking-suspected-at-utah-farm-bureau-presidents-operation/   More Places You Can Listen to Off-Farm Income And Matt Brechwald:    

Jim (Hyphen) Nielsen joins Jerod & Nick for a fun conversation about language-level toll roads, when (and how) to quit, the stratification of social networking & the state of the world in publishing your thoughts on the internet.

Val Town is a shiny, new social programming environment to write, run, deploy and share code. Steve Krouse –Val Town creator– joins Jerod & Amal to tell us all about it.

Jens Neuse, founder of Wundergraph, joins SE Radio host Jeff Doolittle for a conversation about back ends for front ends, or BFF. Jens begins by explaining how a heavy integration burden is often placed on front-end development teams. When multiple APIs must be integrated, it can be challenging for client development in web, mobile, and desktop environments. Explaining how APIs should be treated as dependencies, just like packages, the episode explores BFF patterns and use cases, as well as the future potential emergence of a “git for APIs” standard. This episode is sponsored by ClickSend. 

Ron starts this episode talking about a 16 Grand Cherokee with an aftermarket radio where the USB ports stopped working : takes a call on an 09 Rav 4 with a non working blower and no power to the console : takes a call discussing the power grid and solar farms and EV's : takes a call on a 15 Silverado with a noise in the back end that no one can identify : answers an email on an F550 with a fan clutch problem. Visit us at https://www.cardoctorshow.com  See omnystudio.com/listener for privacy information.

KBall and Amal go deep on careers. They share their career journeys, talk through learnings and mishaps that happened along the way, and break down key factors to understand about big role transitions like “Senior->Staff” as well as “Engineer->Manager”.

We have been getting so many questions on how we run our business together! Today's episode will share share all about how exactly we manage the backend of our business and what we have learned along the way - from the set up of each business, to finances and retail, to our room set up and social media. If you have questions following this episode, contact us through the links below! DRINK: San Pellegrino Pomegranite Black Currant CONNECT WITH US: Please share your thoughts on this episode with me in IG Stories / DM me, I would love to hear from you. Follow us:  ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠@theskyndistillery⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠and ⁠⁠⁠⁠⁠⁠@theskyndistillerylounge⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠Leave us a Voice Message⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠Current offers + Freebies available Here⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Learn More how to Work with us by Clicking Here --- Send in a voice message: https://podcasters.spotify.com/pod/show/theskyndistillerylounge/message Support this podcast: https://podcasters.spotify.com/pod/show/theskyndistillerylounge/support

From the frontend through the kernel to the backend processWhen we send a request to a backend most of us focus on the processing aspect of the request which is really just the last step. There is so much more happening before a request is ready to be processed, most of this step happens in the Kernel. I break this into 6 steps, each step can theoretically be executed by a dedicated thread or process. Pretty much all backends, web servers, proxies, frameworks and even databases have to do all these steps and they all do choose to do it differently. Grab my backend performance course https://performance.husseinnasser.com 0:00 Intro 3:50 What is a Request? 10:14 Step 1 - Accept  21:30 Step 2 - Read 29:30 Step 3 - Decrypt 34:00 Step 4 - Parse 40:36 Step 5 - Decode 43:14 Step 6 - Process Medium article https://medium.com/@hnasr/the-journey-of-a-request-to-the-backend-c3de704de223

Rohit Ratan Mani: The Power of Perspective in Unveiling the Meaning Behind Back-End Work for a Scrum Team Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Rohit discusses his experience as a Scrum Master working with a back-end team suffering from high attrition rates. He realizes that the team members feel undervalued and that the monotonous work is affecting their motivation. To address this, he arranged a workshop with the team and leaders, where the team gained new insights into their importance to the organization. The workshop helped the team see the bigger picture and meaning behind their work, revitalizing their motivation. The key takeaway is the significance of creating opportunities for teams to understand their value and fostering open communication to prevent attrition. Featured Book of the Week: The Five Dysfunctions Of A Team by Lencioni Rohit discusses "The Five Dysfunctions of a Team" by Lencioni, which provides valuable insights into team dynamics. The book helped him understand the hidden dynamics within teams and enabled him to observe and analyze their functioning. It particularly highlighted the significance of trust and conflict in team success. Rohit emphasizes the need for adaptability when working with different teams, as each team is unique and requires a tailored approach. Overall, the book enhanced his understanding of how teams work together and his role within them, emphasizing the importance of trust and conflict resolution.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Rohit Ratan Mani Rohit is an Enterprise Agile Coach, helping Leaders, individuals and teams to develop a growth mindset to be top achievers in their respective work area and  in personal life. You can link with Rohit Ratan Mani on LinkedIn and connect with Rohit Ratan Mani on Twitter.

Una & Adam from The CSS Podcast defend their Frontend Feud title against challengers Chuck & Robbie from Whiskey Web and Whatnot. Let's get it on!

#airtable #on2air #builtonair 7/25/2023 - BuiltOnAir Live Podcast Full Show - S15-E03 ___________________________ The BuiltOnAir podcast is a live weekly show highlighting everything happening in the Airtable universe. Check us out at BuiltOnAir.com/join. Join our community, join our Slack channel, and see what's happening. ------------------------ SPONSORED BY On2Air - Airtable Apps and Integrations to run your business operations in Airtable Start a free 14-day trial of On2Air Apps - https://on2air.com?via=podcast ------------------------ ___________________________ IN THIS EPISODE

In this episode of our Summer Remix series, we are discussing the pros & cons of going directly into a membership versus a back-end membership. Find the full show notes & resources here: https://onlinemarketingpodcast.com/summer-remix-series-going-directly-into-a-membership-vs-back-end-memberships/

Are you considering signing up to the coding bootcamp, Nucamp? Our guests - recent graduates of Nucamp, candidly share their experiences, discussing the highs and lows, what works and what could be better. This conversation is packed with invaluable insights and advice. Listen in for a real, raw, and completely frank perspective on Nucamp.Zynkah (guest):Linkedin - https://www.linkedin.com/in/zena-crepsTwitch - https://www.twitch.tv/zynkahFrancisco Aparicio (guest):Linkedin - https://www.linkedin.com/in/francisco-a-78ba8811aWebsite - https://www.franciscoaparicio.devMichael R (guest):Linkedin - https://www.linkedin.com/in/mjraymondWebsite - https://michaelraymond.dev---------------------------------------------------

Daryl Ruiter joins Baskin & Phelps (Dan Menningen in for Andy Baskin) to discuss the Cleveland Browns roster spots, why he believes 45 of the 53 roster spots have been filled, and why there may be some difficult decisions for the Browns to make at the wide receiver position.

Justin Fagnani joins us this week to talk about Lit, a library that helps you build web components. With 17% of pageviews in Chrome registering use of web components, Lit has gained widespread adoption across a variety of companies looking to create reusable components which leverage the power and interoperability of the web platform. Tune in to learn about what makes this tiny library so incredibly lit!

Justin Fagnani joins us this week to talk about Lit, a library that helps you build web components. With 17% of pageviews in Chrome registering use of web components, Lit has gained widespread adoption across a variety of companies looking to create reusable components which leverage the power and interoperability of the web platform. Tune in to learn about what makes this tiny library so incredibly lit!

Inngest, an open-source startup that helps developers build and manage serverless queues, background jobs and workflows.

En este episodio, quiero que hablemos sobre 10 preguntas posibles de entrevista laboral para backend developers. --- Support this podcast: https://podcasters.spotify.com/pod/show/fernando-her85/support

Austin Gil returns to JS Party, bringing a fresh perspective on the fundamentals of file uploads. Brace for an insightful session as we navigate the complexities of this key JavaScript topic together, much like a dedicated coach drilling the fundamentals into his team!

Austin Gil returns to JS Party, bringing a fresh perspective on the fundamentals of file uploads. Brace for an insightful session as we navigate the complexities of this key JavaScript topic together, much like a dedicated coach drilling the fundamentals into his team!

Liv Erickson is the ecosystem development lead at Mozilla focusing on innovation in spatial computing and AI technologies, and they are the former director of the Mozilla Hubs team. They gave a presentation at the XR Access Symposium that they summarizes in their blog post on "Multidimensional computing accessibility in the age of XR and AI," and they also facilitated a break-out session on Spatial Computing, Data, and AI. I had a chance to catch up with them at the start of the second day to talk about their talk, highlights from the break-out group, and their other blog post exploring how "In the Era of Multi-Dimensional Computing, XR is the Future of Front-End; AI is the Future of Back-End." There is a lot of potential in the future of AI and personalized assistants for accessibility, but also how this intersects with the increased communication capacities and collaborative sensemaking potentials of spatial computing and immersive storytelling. Erikson suggests that perhaps we should think about AI as more as "Augmented Intelligence" rather than "Artificial Intelligence" as a semantic shift that contextualizes AI as a human-centered technology in the spirit of the 10 principles of in Mozilla's Manifesto with 4 addendums towards a healthy Internet. We explore all of that and more within this brief discussion. This is a listener-supported podcast through the Voices of VR Patreon. Music: Fatality

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.

Darcy Clarke, former GitHub Staff Engineering Manager and founder of vlt, joins us to discuss a major bug in the npm ecosystem that he recently disclosed. We cover the bug's timeline, nuances, and impact, all while setting some important context on npm packages, clients, and registries. Tune in to learn how to protect your codebase and gain a deeper understanding of this crucial part of the JavaScript ecosystem.

Darcy Clarke, former GitHub Staff Engineering Manager and founder of vlt, joins us to discuss a major bug in the npm ecosystem that he recently disclosed. We cover the bug's timeline, nuances, and impact, all while setting some important context on npm packages, clients, and registries. Tune in to learn how to protect your codebase and gain a deeper understanding of this crucial part of the JavaScript ecosystem.

When most entrepreneurs think of speaking, they think of either professional speakers charging a fee for their talk or speaking for free to get experience to eventually command a fee. But this concept of trading money for time wasn't why you built your business, and speaking for free without a strategy isn't going to lead you towards the results you want. The good news is that this isn't the only way to speak to get results in your business.  In today's episode, I'm sharing with you my interview on the Sweet Life Podcast with April Beach where I explain the two types of speaking business models you can use to grow your business. We're going to dig into my unique approach to sales and will share with you the step by step process to effectively use speaking opportunities into a money maker for your biz.This conversation is filled with GOLD and tangible strategies so be sure you don't miss this one!In this podcast interview with April, I share:How speaking fits into your business and how you can leverage this to grow your businessThe types of Speaking Business Models and understanding which one aligns with your goals and strategiesThe importance of having a signature talk—one that connects to your offers and to the solutions that you provideWhy listening to your prospect and understanding the context of their problems are critical steps for a successful sales callMy unique approach to sales—3 steps that you can follow to effectively use speaking to grow your businessEPISODE  SHOW NOTES

"استكشف عالم "الباك اند" الغير مرئي والتأثير الهائل له على حياتنا اليومية في أحدث حلقات بودكاستنا، "The Backend - عندما يأتي الباك اند للانقاذ: هل هو سوبرمان في عالم التقنية؟". هذا الغوص العميق يكشف العمود الفقري للتطبيقات التقنية، اكتشف كيف تستغل هذه الشركات البنية التحتية الخلفية لدفع النجاح والابتكار. تعرف على الاتجاهات المستقبلية في "الباك اند"؟ وكيفية تشكيلها للمشهد الرقمي. هذه الحلقة ضرورية لأي شخص مهتم في فهم ما يحدث خلف الكواليس!" احنا عارفين ان الباك اند ممكن تكون معقدة جدا بس فضلنا نتكلم بشكل خفيف زي وصفة طبخ في مطبخ زحمة، لاكن حاولنا في الحلقة انه يكون خفيف يظبط اكتر مع فنجان قهوة تمام .... تمام ؟ "Explore the unseen world of 'the backend' and its immense impact on our daily lives in our latest podcast episode, 'The Backend - When Backend Comes to the Rescue: Is It Superman in the Tech World?'. This deep dive unveils the backbone of technological applications. Discover how these companies exploit backend infrastructure to drive success and innovation. Learn about the future trends in 'the backend'? And how they shape the digital landscape. This episode is essential for anyone interested in understanding what happens behind the scenes! We know that the backend can be very complex, but we decided to discuss it light-heartedly much like a cooking recipe in a bustling kitchen, yet we tried to make the episode light and enjoyable with a cup of coffee .... okay? Okay?" Links: روابط https://linktr.ee/iahmadzain Guest: ضيوف https://twitter.com/iahmadzain https://www.instagram.com/adam.sh3.0 http://twitter.com/hazemkhaled #الباك_اند #التطبيقات_العملية #دراسات_الحالة #عمالقة_التكنولوجيا #فيسبوك #نتفليكس #أمازون #جوجل #البنية_التحتية #الاتجاهات_المستقبلية #المشهد_الرقمي #الأمن_السيبراني #تخزين_البيانات #التخصيص #التجارة_الإلكترونية #محركات_البحث #الهندسة_المعمارية_بدون_خادم #الميكروسيرفسز #النجاح_التجاري #الابتكار #BackendDevelopment #RealLifeApplications #CaseStudies #TechGiants #Facebook #Netflix #Amazon #Google #BackendInfrastructure #FutureTrends #DigitalLandscape #Cybersecurity #DataStorage #Personalization #Ecommerce #SearchEngines #ServerlessArchitecture #Microservices #BusinessSuccess #Innovation

Bailey & Jesse chat with the Director of Turing's Backend Program and Turing Alum Amy Holt about her Turing Story, her career at Turing, management, the future of the Backend program, and . If you or someone you know are code curious, we encourage you to attend a Turing Try Coding Event. You can register for a free Try Coding class at turing.edu/try-coding.

In a wonderful blog, Kyle explores the pains he faced managing a Postgres instance for a startup he works for and how enabling partitioning sigintfically created wait events causing the backend and subsequently NGINX to through 500 errors. We discuss this in this video/podcast https://www.kylehailey.com/post/postgres-partition-pains-lockmanager-waits

const podcast = { episode: 239, title: 'Scaling BackEnd APIs', topics: [ 'API', 'python', 'backend' ], guest: 'Bornwell Matembudze' hosts: [ 'John Papa', 'Craig Shoemaker' ]};Recording date: June 5, 2023John Papa @John_PapaWard Bell @WardBellDan Wahlin @DanWahlinCraig Shoemaker @craigshoemakerBornwell Matembudze @Bornie_21Brought to you byAG GridNarwhal Visit nx.dev to get the preeminent open-source toolkit for monorepo development, today. Resources:Bornwell Matembudze on Web Rush 137GitHub ActionsJenkinsDon't be scared of CSSWhy Developers Fear CSSCSS FloatOverengineering in software developmentRabbitMQWelcome to Python.orgFlaskDjangoAdobe After EffectsEDA Event Driven Architecture -Event BrokersEvent Driven Architecture with RabbitMQMicroservices Event Driven Architecture with RabbitMQ and Docker Container on .NETCreating a Scalable API with microservicesAzure Container AppsMicroservices are not the answer to everythingTimejumps00:23 Doesn't John know who he is?02:37 Introducing Bornwell Matembudze05:01 How do you start developing with a scalable API in mind?09:06 Sponsor: Ag Grid10:07 What are backend APIs?14:11 How do you scale effectively?15:40 What is Event Driven Architecture?17:32 Sponsor: Nrwl18:03 How does EDA and RabbitMQ help you scale an API?20:39 Synchronous vs asynchronous?23:20 Example of customers and orders25:43 How do you handle testing?27:12 Final thoughtsPodcast editing on this episode done by Chris Enns of Lemon Productions.

Let's debate debugging techniques! Do you print debug or dive deep into debugging tools? KBall & Jerod argue that print statements are all you need while Amal & guest Eric Clemmons take the other side. Who will win and why will it be Jerod?

Support us on Patreon for BONUS episodes each month & other perks: https://www.patreon.com/thesavegpodcast We are back from Houston, alive and well. We shared a bit about the trip and some of the restaurants we hit up- the food was soo good! In this week's episode we kick off discussing the recent backlash Cracker Barrel restaurant chain faced after posting pride month ad- stating everyone is welcome in their restaurants. Rose has a little cry about the c**k sauce shortage- which highlights wider issues around global warming and global food supplies. NYC and parts of the US hit with smoke from Canada's forest fires. AI company OpenAI faces a lawsuit as a radio show host sues for defamation from their ChatGPT- could this be a landmark case in this space and create more challenges for AI? Lastly we talk about Reddit cracking down on developers using their back end- and they are going to start charging for some back end access. Hope you guys enjoyed the episode! THAILAND - https://www.trovatrip.com/trip/asia/thailand/thailand-with-rose-lee-aug-2023 BALI - https://www.trovatrip.com/trip/asia/bali/indonesia-with-rose-lee-aug-2023

"Even though they're not going forward for a particular reason with their fit for their organization, that doesn't mean that they can't reach out to somebody else that they know because of the experience, then their circumstance might be different." - Carl Sajous in today's Tip 1578 Do you do front-end and back-end referrals? Join the conversation at DailySales.Tips/1578 and check out the full interview with Carl! Have feedback? Want to share a sales tip? Call or text the Sales Success Hotline: 512-777-1442 or Email: scott@top1.fm

The panel dives into all of the supporting structures that we build around writing code, what works in different environments, and good and bad practices they have seen. From PR etiquette to CI/CD to how to write a ticket, they look at them from an open source perspective, an enterprise perspective, and everything in between.