Podcasts about Git

About StephanieStephanie Wong is an award-winning speaker, engineer, pageant queen, and hip hop medalist. She is a leader at Google with a mission to blend storytelling and technology to create remarkable developer content. At Google, she's created over 400 videos, blogs, courses, and podcasts that have helped developers globally. You might recognize her as the host of the GCP Podcast. Stephanie is active in her community, fiercely supporting women in tech and mentoring students.Links: Personal Website: https://stephrwong.com Twitter: https://twitter.com/stephr_wong 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 Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And—let me be clear here—it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free, no asterisk. Start now. Visit snark.cloud/oci-free that's snark.cloud/oci-free.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the things that makes me a little weird in the universe is that I do an awful lot of… let's just call it technology explanation slash exploration in public, and turning it into a bit of a brand-style engagement play. What makes this a little on the weird side is that I don't work for a big company, which grants me a tremendous latitude. I have a whole lot of freedom that lets me be all kinds of different things, and I can't get fired, which is something I'm really good at.Inversely, my guest today is doing something remarkably similar, except she does work for a big company and could theoretically be fired if they were foolish enough to do so. But I don't believe that they are. Stephanie Wong is the head of developer engagement at Google. Stephanie, thank you for volunteering to suffer my slings and arrows about all of this.Stephanie: [laugh]. Thanks so much for having me today, Corey.Corey: So, at a very high level, you're the head of developer engagement, which is a term that I haven't seen a whole lot of. Where does that start and where does that stop?Stephanie: Yeah, so I will say that it's a self-proclaimed title a bit because of the nuance of what I do. I would say at its heart, I am still a part of developer relations. If you've heard of developer advocacy or developer evangelist, I would say this slight difference in shade of what I do is that I focus on scalable content creation and becoming a central figure for our developer audiences to engage and enlighten them with content that, frankly, is remarkable, and that they'd want to share and learn about our technology.Corey: Your bio is fascinating in that it doesn't start with the professional things that most people do with, “This is my title and this is my company,” is usually the first sentence people put in. Yours is, “Stephanie Wong is an award-winning speaker, engineer, pageant queen, and hip hop medalist.” Which is both surprising and more than a little bit refreshing because when I read a bio like that my immediate instinctive reaction is, “Oh, thank God. It's a real person for a change.” I like the idea of bringing the other aspects of what you are other than, “This is what goes on in an IDE, the end,” to your audience.Stephanie: That is exactly the goal that I had when creating that bio because I truly believe in bringing more interdisciplinary and varied backgrounds to technology. I, myself have gone through a very unconventional path to get to where I am today and I think in large part, my background has had a lot to do with my successes, my failures, and really just who I am in tech as an uninhibited and honest, credible person today.Corey: I think that there's a lack of understanding, broadly, in our industry about just how important credibility and authenticity are and even the source of where they come from. There are a lot of folks who are in the DevRel space—devrelopers, as I insist upon calling them, over their protests—where, on some level, the argument is, what is developer relations? “Oh, you work in marketing, but they're scared to tell you,” has been my gag on that one for a while. But they speak from a position of, “I know what's what because I have been in the trenches, working on these large-scale environments as an engineer for the last”—fill in the blank, however long it may have been—“And therefore because I have done things, I am going to tell you how it is.” You explicitly call out that you don't come from the traditional, purely technical background. Where did you come from? It's unlikely that you've sprung fully-formed from the forehead of some god, but again, I'm not entirely sure how Google finds and creates the folks that it winds up advancing, so maybe you did.Stephanie: Well, to tell you the truth. We've all come from divine creatures. And that's where Google sources all employees. So. You know. But—[laugh].Corey: Oh, absolutely. “We climbed to the top of Olympus and then steal fire from the gods.” “It's like, isn't that the origin story of Prometheus?” “Yeah, possibly.” But what is your background? Where did you come from?Stephanie: So, I have grown up, actually, in Silicon Valley, which is a little bit ironic because I didn't go to school for computer science or really had the interest in becoming an engineer in school. I really had no idea.Corey: Even been more ironic than that because most of Silicon Valley appears to never have grown up at all.Stephanie: [laugh]. So, true. Maybe there's a little bit of that with me, too. Everybody has a bit of Peter Pan syndrome here, right? Yeah, I had no idea what I wanted to do in school and I just knew that I had an interest in communicating with one another, and I ended up majoring in communication studies.I thought I wanted to go into the entertainment industry and go into production, which is very different and ended up doing internships at Warner Brothers Records, a YouTube channel for dance—I'm a dancer—and I ended up finding a minor in digital humanities, which is sort of this interdisciplinary minor that combines technology and the humanities space, including literature, history, et cetera. So, that's where I got my start in technology, getting an introduction to information systems and doing analytics, studying social media for certain events around the world. And it wasn't until after school that I realized that I could work in enterprise technology when I got an offer to be a sales engineer. Now, that being said, I had no idea what sales engineering was. I just knew it had something to do with enterprise technology and communications, and I thought it was a good fit for my background.Corey: The thing that I find so interesting about that is that it breaks the mold of what people expect, when, “If someone's going to talk to me about technology—especially coming from a”—it's weird; it's one of the biggest companies on the planet, and people still on some level equate Google with the startup-y mentality of being built in someone's garage. That's an awfully big garage these days, if that's even slightly close to true, which it isn't. But there's this idea of, “Oh, you have to go to Stanford. You have to get a degree in computer science. And then you have to go and do this, this, this, this, and this.”And it's easy to look dismissively at what you're doing. “Communications? Well, all that would teach you to do is communicate to people clearly and effectively. What possible good is that in tech?” As we look around the landscape and figure out exactly why that is so necessary in tech, and also so lacking?Stephanie: Exactly. I do think it's an underrated skill in tech. Maybe it's not so much anymore, but I definitely think that it has been in the past. And even for developers, engineers, data scientists, other technical practitioner, especially as a person in DevRel, I think it's such a valuable skill to be able to communicate complex topics simply and understandably to a wide variety of audiences.Corey: The big question that I have for you because I've talked to an awful lot of folks who are very concerned about the way that they approach developer relations, where—they'll have ratios, for example—where I know someone and he insists that he give one deeply technical talk for every four talks that are not deeply technical, just because he feels the need to re-establish and shore up his technical bona fides. Now, if there's one thing that people on the internet love, it is correcting people on things that are small trivia aspect, or trying to pull out the card that, “Oh, I've worked on this system for longer than you've worked on this system, therefore, you should defer to me.” Do you find that you face headwinds for not having the quote-unquote, “Traditional” engineering technical background?Stephanie: I will say that I do a bit. And I did, I would say when I first joined DevRel, and I don't know if it was much more so that it was being imposed on me or if it was being self-imposed, something that I felt like I needed to prove to gain credibility, not just in my organization, but in the industry at large. And it wasn't until two or three years into it, that I realized that I had a niche myself. It was to create stories with my content that could communicate these concepts to developers just as effectively. And yes, I can still prove that I can go into an hour-long or a 45-minute-long tech talk or a webinar about a topic, but I can also easily create a five to ten-minute video that communicates concepts and inspires audiences just the same, and more importantly, be able to point to resources, code labs, tutorials, GitHub repos, that can allow the audience to be hands-on themselves, too. So really, I think that it was over time that I gained more experience and realized that my skill sets are valuable in a different way, and it's okay to have a different background as long as you bring something to the table.Corey: And I think that it's indisputable that you do. The concept of yours that I've encountered from time to time has always been insightful, it is always been extremely illuminating, and—you wouldn't think of this as worthy of occasion and comment, but I feel it needs to be said anyway—at no point in any of your content did I feel like I was being approached in a condescending way, where at every point it was always about uplifting people to a level of understanding, rather than doing the, “Well, I'm smarter than you and you couldn't possibly understand the things that I've been to.” It is relatable, it is engaging, and you add a very human face to what is admittedly an area of industry that is lacking in a fair bit of human element.Stephanie: Yeah, and I think that's the thing that many folks DevRel continue to underline is the idea of empathy, empathizing with your audiences, empathizing with the developers, the engineers, the data engineers, whoever it is that you're creating content for, it's being in their shoes. But for me, I may not have been in those shoes for years, like many other folks historically have been in for DevRel, but I want to at least go through the journey of learning a new piece of technology. For example, if I'm learning a new platform on Google Cloud, going through the steps of creating a demo, or walking through a tutorial, and then candidly explaining that experience to my audience, or creating a video about it. I really just reject the idea of having ego in tech and I would love to broaden the opportunity for folks who came from a different background like myself. I really want to just represent the new world of technology where it wasn't full of people who may have had the privilege to start coding at a very early age, in their garages.Corey: Yeah, privilege of, in many respects, also that privilege means, “Yes, I had the privilege of not having to have friends and deal with learning to interact with other human beings, which is what empowered me to build this company and have no social skills whatsoever.” It's not the aspirational narrative that we sometimes are asked to believe. You are similar in some respects to a number of things that I do—by which I mean, you do it professionally and well and I do it as basically performance shitpost art—but you're on Twitter, you make videos, you do podcasts, you write long-form and short-form as well. You are sort of all across the content creation spectrum. Which of those things do you prefer to do? Which ones of those are things you find a little bit more… “Well, I have to do it, but it's not my favorite?” Or do you just tend to view it as content is content; you just look at different media to tell your story?Stephanie: Well, I will say any form of content is queen—I'm not going to say king, but—[laugh] content is king, content is queen, it doesn't matter.Corey: Content is a baroness as it turns out.Stephanie: [laugh]. There we go. I have to say, so given my background, I mentioned I was into production and entertainment before, so I've always had a gravitation towards video content. I love tinkering with cameras. Actually, as I got started out at Google Cloud, I was creating scrappy content using webcams and my own audio equipment, and doing my own research, and finding lounges and game rooms to do that, and we would just upload it to our own YouTube channel, which probably wasn't allowed at the time, but hey, we got by with it.And eventually, I got approached by DevRel to start doing it officially on the channel and I was given budget to do it in-studio. And so that was sort of my stepping stone to doing this full-time eventually, which I never foresaw for myself. And so yeah, I have this huge interest in—I'm really engaged with video content, but once I started expanding and realizing that I could repurpose that content for podcasting, I could repurpose it for blogs, then you start to realize that you can shard content and expand your reach exponentially with this. So, that's when I really started to become more active on social media and leverage it to build not just content for Google Cloud, but build my own brand in tech.Corey: That is the inescapable truth of DevRel done right is that as you continue doing it, in time, in your slice of the industry, it is extremely likely that your personal brand eclipses the brand of the company that you represent. And it's in many ways a test of corporate character—if it makes sense—as do how they react to that. I've worked in roles before I started this place where I was starting to dabble with speaking a lot, and there was always a lot of insecurity that I picked up of, “Well, it feels like you're building your personal brand, not advancing the company here, and we as a company do not see the value in you doing that.” Direct quote from the last boss I had. And, well, that partially explains why I'm here, I suppose.But there's insecurity there. I'd see the exact opposite coming out of Google, especially in recent times. There's something almost seems to be a renaissance in Google Cloud, and I'm not sure where it came from. But if I look at it across the board, and you had taken all the labels off of everything, and you had given me a bunch of characteristics about different companies, I would never have guessed that you were describing Google when you're talking about Google Cloud. And perhaps that's unfair, but perceptions shape reality.Stephanie: Yeah, I find that interesting because I think traditionally in DevRel, we've also hired folks for their domain expertise and their brand, depending on what you're representing, whether it's in the Kubernetes space or Python client library that you're supporting. But it seems like, yes, in my case, I've organically started to build my brand while at Google, and Google has been just so spectacular in supporting that for me. But yeah, it's a fine line that I think many people have to walk. It's like, do you want to continue to build your own brand and have that carry forth no matter what company you stay at, or if you decide to leave? Or can you do it hand-in-hand with the company that you're at? For me, I think I can do it hand-in-hand with Google Cloud.Corey: It's taken me a long time to wrap my head around what appears to be a contradiction when I look at Google Cloud, and I think I've mostly figured it out. In the industry, there is a perception that Google as an entity is condescending and sneering toward every other company out there because, “You're Google, you know how to do all these great, amazing things that are global-spanning, and over here at Twitter for Pets, we suck doing these things.” So, Google is always way smarter and way better at this than we could ever hope to be. But that is completely opposed to my personal experiences talking with Google employees. Across the board, I would say that you all are self-effacing to a fault.And I mean that in the sense of having such a limited ego, in some cases, that it's, “Well, I don't want to go out there and do a whole video on this. It's not about me, it's about the technology,” are things that I've had people who work at Google say to me. And I appreciate the sentiment; it's great, but that also feels like it's an aloofness. It also fails to humanize what it is that you're doing. And you are a, I've got to say, a breath of fresh air when it comes to a lot of that because your stories are not just, “Here's how you do a thing. It's awesome. And this is all the intricacies of the API.”And yeah, you get there, but you also contextualize that in a, “Here's why it matters. Here's the problem that solves. Here is the type of customer's problem that this is great for,” rather than starting with YAML and working your way up. It's going the other way, of, “We want to sell some underpants,” or whatever it is the customer is trying to do today. And that is the way that I think is one of the best ways to drive adoption of what's going on because if you get people interested and excited about something—at least in my experience—they're going to figure out how the API works. Badly in many cases, but works. But if you start on the API stuff, it becomes a solution looking for a problem. I like your approach to this.Stephanie: Thank you. Yeah, I appreciate that. I think also something that I've continued to focus on is to tell stories across products, and it doesn't necessarily mean within just Google Cloud's ecosystem, but across the industry as well. I think we need to, even at Google, tell a better story across our product space and tie in what developers are currently using. And I think the other thing that I'm trying to work on, too, is contextualizing our products and our launches not just across the industry, but within our product strategy. Where does this tie in? Why does it matter? What is our forward-looking strategy from here? When we're talking about our new data cloud products or analytics, [unintelligible 00:17:21], how does this tie into our API strategy?Corey: And that's the biggest challenge, I think, in the AI space. My argument has been for a while—in fact, I wrote a blog post on it earlier this year—that AI and machine learning is a marvelously executed scam because it's being pushed by cloud providers and the things that you definitely need to do a machine learning experiment are a bunch of compute and a whole bunch of data that has to be stored on something, and wouldn't you know it, y'all sell that by the pound. So, it feels, from a cynical perspective, which I excel at espousing, that approach becomes one of you're effectively selling digital pickaxes into a gold rush. Because I see a lot of stories about machine learning how to do very interesting things that are either highly, highly use-case-specific, which great, that would work well, for me too, if I ever wind up with, you know, a petabyte of people's transaction logs from purchasing coffee at my national chain across the country. Okay, that works for one company, but how many companies look like that?And on the other side of it, “It's oh, here's how we can do a whole bunch of things,” and you peel back the covers a bit, and it looks like, “Oh, but you really taught me here is bias laundering?” And, okay. I think that there's a definite lack around AI and machine learning of telling stories about how this actually matters, what sorts of things people can do with it that aren't incredibly—how do I put this?—niche or a problem in search of a solution?Stephanie: Yeah, I find that there are a couple approaches to creating content around AI and other technologies, too, but one of them being inspirational content, right? Do you want to create something that tells the story of how I created a model that can predict what kind of bakery item this is? And we're going to do it by actually showcasing us creating the outcome. So, that's one that's more like, okay. I don't know how relatable or how appropriate it is for an enterprise use case, but it's inspirational for new developers or next gen developers in the AI space, and I think that can really help a company's brand, too.The other being highly niche for the financial services industry, detecting financial fraud, for example, and that's more industry-focused. I found that they both do well, in different contexts. It really depends on the channel that you're going to display it on. Do you want it to be viral? It really depends on what you're measuring your content for. I'm curious from you, Corey, what you've seen across, as a consumer of content?Corey: What's interesting, at least in my world, is that there seems to be, given that what I'm focusing on first and foremost is the AWS ecosystem, it's not that I know it the best—I do—but at this point, it's basically Stockholm Syndrome where it's… with any technology platform when you've worked with it long enough, you effectively have the most valuable of skill sets around it, which is not knowing how it works, but knowing how it doesn't, knowing what the failure mode is going to look like and how you can work around that and detect it is incredibly helpful. Whereas when you're trying something new, you have to wait until it breaks to find the sharp edges on it. So, there's almost a lock-in through, “We failed you enough times,” story past a certain point. But paying attention to that ecosystem, I find it very disjointed. I find that there are still events that happen and I only find out when the event is starting because someone tweets about it, and for someone who follows 40 different official AWS RSS feeds, to be surprised by something like that tells me, okay, there's not a whole lot of cohesive content strategy here, that is at least making it easy for folks to consume the things that they want, especially in my case where even the very niche nature of what I do, my interest is everything.I have a whole bunch of different filters that look for various keywords and the rest, and of course, I have helpful folks who email me things constantly—please keep it up; I'm a big fan—worst case, I'd rather read something twice than nothing. So, it's helpful to see all of that and understand the different marketing channels, different personas, and the way that content approaches, but I still find things that slip through the cracks every time. The thing that I've learned—and it felt really weird when I started doing it—was, I will tell the same stories repeatedly in different forums, or even the same forum. I could basically read you a Twitter thread from a year ago, word-for-word, and it would blow up bigger than it did the first time. Just because no one reads everything.Stephanie: Exactly.Corey: And I've already told my origin story. You're always new to someone. I've given talks internally at Amazon at various times, and I'm sort of loud and obnoxious, but the first question I love to ask is, “Raise your hand if you've never heard of me until today.” And invariably, over three-quarters of the room raises their hand every single time, which okay, great. I think that's awesome, but it teaches me that I cannot ever expect someone to have, quote-unquote, “Done the reading.”Stephanie: I think the same can be said about the content that I create for the company. You can't assume that people, A) have seen my tweets already or, B) understand this product, even if I've talked about it five times in the past. But yes, I agree. I think that you definitely need to have a content strategy and how you format your content to be more problem-solution-oriented.And so the way that I create content is that I let them fall into three general buckets. One being that it could be termed definition: talking about the basics, laying the foundation of a product, defining terms around a topic. Like, what is App Engine, or Kubeflow 101, or talking about Pub/Sub 101.The second being best practices. So, outlining and explaining the best practices around a topic, how do you design your infrastructure for scale and reliability.And the third being diagnosis: investigating; exploring potential issues, as you said; using scripts; Stackdriver logging, et cetera. And so I just kind of start from there as a starting point. And then I generally follow a very, very effective model. I'm sure you're aware of it, but it's called the five point argument model, where you are essentially telling a story to create a compelling narrative for your audience, regardless of the topic or what bucket that topic falls into.So, you're introducing the problem, you're sort of rising into a point where the climax is the solution. And that's all to build trust with your audience. And as it falls back down, you're giving the results in the conclusion, and that's to inspire action from your audience. So, regardless of what you end up talking about this problem-solution model—I've found at least—has been highly effective. And then in terms of sharing it out, over and over again, over the span of two months, that's how you get the views that you want.Corey: This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals. Having the highest quality content in tech and cloud skills, and building a good community the is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. Its both useful for individuals and large enterprises, but here's what makes it new. I don't use that term lightly. Cloud Academy invites you to showcase just how good your AWS skills are. For the next four weeks you'll have a chance to prove yourself. Compete in four unique lab challenges, where they'll be awarding more than $2000 in cash and prizes. I'm not kidding, first place is a thousand bucks. Pre-register for the first challenge now, one that I picked out myself on Amazon SNS image resizing, by visiting cloudacademy.com/corey. C-O-R-E-Y. That's cloudacademy.com/corey. We're gonna have some fun with this one!Corey: See, that's a key difference right there. I don't do anything regular in terms of video as part of my content. And I do it from time to time, but you know, getting gussied up and whatnot is easier than just talking into a microphone. As I record this, it's Friday, I'm wearing a Hawaiian shirt, and I look exactly like the middle-aged dad that I am. And for me at least, a big breakthrough moment was realizing that my audience and I are not always the same.Weird confession for someone in my position: I don't generally listen to podcasts. And the reason behind that is I read very quickly, and even if I speed up a podcast, I'm not going to be able to consume the information nearly as quickly as I could by reading it. That, amongst other reasons, is one of the reasons that every episode of this show has a full transcript attached to it. But I'm not my audience. Other people prefer to learn by listening and there's certainly nothing wrong with that.My other podcast, the AWS Morning Brief, is the spoken word version of the stuff that I put out in my newsletter every week. And that is—it's just a different area for people to consume the content because that's what works for them. I'm not one to judge. The hard part for me was getting over that hump of assuming the audience was like me.Stephanie: Yeah. And I think the other key part of is just mainly consistency. It's putting out the content consistently in different formats because everybody—like you said—has a different learning style. I myself do. I enjoy visual styles.I also enjoy listening to podcasts at 2x speed. [laugh]. So, that's my style. But yeah, consistency is one of the key things in building content, and building an audience, and making sure that you are valuable to your audience. I mean, social media, at the end of the day is about the people that follow you.It's not about yourself. It should never be about yourself. It's about the value that you provide. Especially as somebody who's in DevRel in this position for a larger company, it's really about providing value.Corey: What are the breakthrough moments that I had relatively early in my speaking career—and I think it's clear just from what you've already said that you've had a similar revelation at times—I gave a talk, that was really one of my first talks that went semi-big called, “Terrible Ideas in Git.” It was basically, learn how to use Git via anti-pattern. What it secretly was, was under the hood, I felt it was time I learned Git a bit better than I did, so I pitched it and I got a talk accepted. So well, that's what we call a forcing function. By the time I give that talk, I'd better be [laugh] able to have built a talk that do this intelligently, and we're going to hope for the best.It worked, but the first version of that talk I gave was super deep into the plumbing of Git. And I'm sure that if any of the Git maintainers were in the audience, they would have found it great, but there aren't that many folks out there. I redid the talk and instead approached it from a position of, “You have no idea what Git is. Maybe you've heard of it, but that's as far as it goes.” And then it gets a little deeper there.And I found that making the subject more accessible as opposed to deeper into the weeds of it is almost always the right decision from a content perspective. Because at some level, when you are deep enough into the weeds, the only way you're going to wind up fixing something or having a problem that you run into get resolved, isn't by listening to a podcast or a conference talk; it's by talking to the people who built the thing because at that level, those are the only people who can hang at that level of depth. That stops being fodder for conference talks unless you turn it into an after-action report of here's this really weird thing I learned.Stephanie: Yeah. And you know, to be honest, the one of the most successful pieces of content I've created was about data center security. I visited a data center and I essentially unveiled what our security protocols were. And that wasn't a deeply technical video, but it was fun and engaging and easily understood by the masses. And that's what actually ended up resulting in the highest number of views.On top of that, I'm now creating a video about our subsea fiber optic cables. Finding that having to interview experts from a number of different teams across engineering and our strategic negotiators, it was like a monolith of information that I had to take in. And trying to format that into a five-minute story, I realized that bringing it up a layer of abstraction to help folks understand this at a wider level was actually beneficial. And I think it'll turn into a great piece of content. I'm still working on it now. So, [laugh] we'll see how it turns out.Corey: I'm a big fan of watching people learn and helping them get started. The thing that I think gets lost a lot is it's easy to assume that if I look back in time at myself when I was first starting my professional career two decades ago, that I was exactly like I am now, only slightly more athletic and can walk up a staircase without getting winded. That's never true. It never has been true. I've learned a lot about not just technology but people as I go, and looking at folks are entering the workforce today through the same lens of, “Well, that's not how I would handle that situation.” Yeah, no kidding. I have two decades of battering my head against the sharp edges and leaving dents in things to inform that opinion.No, when I was that age, I would have handled it way worse than whatever it is I'm critiquing at the time. But it's important to me that we wind up building those pathways and building those bridges so that people coming into the space, first, have a clear path to get here, and secondly, have a better time than I ever did. Where does the next generation of talent come from has been a recurring question and a recurring theme on the show.Stephanie: Yeah. And that's exactly why I've been such a fierce supporter of women in tech, and also, again, encouraging a broader community to become a part of technology. Because, as I said, I think we're in the midst of a new era of technology, of people from all these different backgrounds in places that historically have had more remote access to technology, now having the ability to become developers at an early age. So, with my content, that's what I'm hoping to drive to make this information more easily accessible. Even if you don't want to become a Google Cloud engineer, that's totally fine, but if I can help you understand some of the foundational concepts of cloud, then I've done my job well.And then, even with women who are already trying to break into technology or wanting to become a part of it, then I want to be a mentor for them, with my experience not having a technical background and saying yes to opportunities that challenged me and continuing to build my own luck between hard work and new opportunities.Corey: I can't wait to see how this winds up manifesting as we see understandings of what we're offering to customers in different areas in different ways—both in terms of content and terms of technology—how that starts to evolve and shift. I feel like we're at a bit of an inflection point now, where today if I graduate from school and I want to start a business, I have to either find a technical co-founder or I have to go to a boot camp and learn how to code in order to build something. I think that if we can remove that from the equation and move up the stack, sure, you're not going to be able to build the next Google or Pinterest or whatnot from effectively Visual Basic for Interfaces, but you can build an MVP and you can then continue to iterate forward and turn it into something larger down the road. The other part of it, too, is that moving up the stack into more polished solutions rather than here's a bunch of building blocks for platforms, “So, if you want a service to tell you whether there's a picture of a hot dog or not, here's a service that does exactly that.” As opposed to, “Oh, here are the 15 different services, you can bolt together and pay for each one of them and tie it together to something that might possibly work, and if it breaks, you have no idea where to start looking, but here you go.” A packaged solution that solves business problems.Things move up the stack; they do constantly. The fact is that I started my career working in data centers and now I don't go to them at all because—spoiler—Google, and Amazon, and people who are not IBM Cloud can absolutely run those things better than I can. And there's no differentiated value for me in solving those global problems locally. I'd rather let the experts handle stuff like that while I focus on interesting problems that actually affect my business outcome. There's a reason that instead of running all the nonsense for lastweekinaws.com myself because I've worked in large-scale WordPress hosting companies, instead I pay WP Engine to handle it for me, and they, in turn, hosted on top of Google Cloud, but it doesn't matter to me because it's all just a managed service that I pay for. Because me running the website itself adds no value, compared to the shitpost I put on the website, which is where the value derives from. For certain odd values of value.Stephanie: [laugh]. Well, two things there is that I think we actually had a demo created on Google Cloud that did detect hot dogs or not hot dogs using our Vision API, years in the past. So, thanks for reminding me of that one.Corey: Of course.Stephanie: But yeah, I mean, I completely agree with that. I mean, this is constantly a topic in conversation with my team members, and with clients. It's about higher level of abstractions. I just did a video series with our fellow, Eric Brewer, who helped build cloud infrastructure here at Google over the past ten decades. And I asked him what he thought the future of cloud would be in the next ten years, and he mentioned, “It's going to be these higher levels of abstraction, building platforms on top of platforms like Kubernetes, and having more services like Cloud run serverless technologies, et cetera.”But at the same time, I think the value of cloud will continue to be providing optionality for developers to have more opinionated services, services like GKE Autopilot, et cetera, that essentially take away the management of infrastructure or nodes that people don't really want to deal with at the end of the day because it's not going to be a competitive differentiator for developers. They want to focus on building software and focusing on keeping their services up and running. And so yeah, I think the future is going to be that, giving developers flexibility and freedom, and still delivering the best-of-breed technology. If it's covering something like security, that's something that should be baked in as much as possible.Corey: You're absolutely right, first off. I'm also looking beyond it where I want to be able to build a website that is effectively Twitter, only for pets—because that is just a harebrained enough idea to probably raise a $20 million seed round these days—and I just want to be able to have the barks—those are like tweets, only surprisingly less offensive and racist—and have them just be stored somewhere, ideally presumably under the hood somewhere, it's going to be on computers, but whether it's in containers, or whether it's serverless, or however is working is the sort of thing that, “Wow, that seems like an awful lot of nonsense that is not central nor core to my business succeeding or failing.” I would say failing, obviously, except you can lose money at scale with the magic of things like SoftBank. Here we are.And as that continues to grow and scale, sure, at some point I'm going to have bespoke enough needs and a large enough scale where I do have to think about those things, but building the MVP just so I can swindle some VCs is not the sort of thing where I should have to go to that depth. There really should be a golden-path guardrail-style thing that I can effectively drag and drop my way into the next big scam. And that is, I think, the missing piece. And I think that we're not quite ready technologically to get there yet, but I can't shake the feeling and the hope that's where technology is going.Stephanie: Yeah. I think it's where technology is heading, but I think part of the equation is the adoption by our industry, right? Industry adoption of cloud services and whether they're ready to adopt services that are that drag-and-drop, as you say. One thing that I've also been talking a lot about is this idea of service-oriented networking where if you have a service or API-driven environment and you simply want to bring it to cloud—almost a plug-and-play there—you don't really want to deal with a lot of the networking infrastructure, and it'd be great to do something like PrivateLink on AWS, or Private Service Connect on Google Cloud.While those conversations are happening with customers, I'm finding that it's like trying to cross the Grand Canyon. Many enterprise customers are like, “That sounds great, but we have a really complex network topology that we've been sitting on for the past 25 years. Do you really expect that we're going to transition over to something like that?” So, I think it's about providing stepping stones for our customers until they can be ready to adopt a new model.Corey: Yeah. And of course, the part that never gets said out loud but is nonetheless true and at least as big of a deal, “And we have a whole team of people who've built their entire identity around that network because that is what they work on, and they have been ignoring cloud forever, and if we just uplift everything into a cloud where you folks handle that, sure, it's better for the business outcome, but where does that leave them?” So, they've been here for 25 years, and they will spend every scrap of political capital they've managed to accumulate to torpedo a cloud migration. So, any FUD they can find, any horse-trading they can do, anything they can do to obstruct the success of a cloud initiative, they're going to do because people are people, and there is no real plan to mitigate that. There's also the fact that unless there's a clear business value story about a feature velocity increase or opening up new markets, there's also not an incentive to do things to save money. That is never going to be the number one priority in almost any case short of financial disaster at a company because everything they're doing is building out increasing revenue, rather than optimizing what they're already doing.So, there's a whole bunch of political challenges. Honestly, moving the computer stuff from on-premises data centers into a cloud provider is the easiest part of a cloud migration compared to all of the people that are involved.Stephanie: Yeah. Yeah, we talked about serverless and all the nice benefits of it, but unless you are more a digitally-born, next-gen developer, it may be a higher burden for you to undertake that migration. That's why we always [laugh] are talking about encouraging people to start with newer surfaces.Corey: Oh, yeah. And that's the trick, too, is if you're trying to learn a new cloud platform these days—first, if you're trying to pick one, I'd be hard-pressed to suggest anything other than Google Cloud, with the possible exception of DigitalOcean, just because the new user experience is so spectacularly good. That was my first real, I guess, part of paying attention to Google Cloud a few years ago, where I was, “All right, I'm going to kick the tires on this and see how terrible this interface is because it's a Google product.” And it was breathtakingly good, which I did not expect. And getting out of the way to empower someone who's new to the platform to do something relatively quickly and straightforwardly is huge. And sure, there's always room to prove, but that is the right area to focus on. It's clear that the right energy was spent in the right places.Stephanie: Yeah. I will say a story that we don't tell quite as well as we should is the One Google story. And I'm not talking about just between Workspace and Google Cloud, but our identity access management and knowing your Google account, which everybody knows. It's not like Microsoft, where you're forced to make an account, or it's not like AWS where you had a billion accounts and you hate them all.Corey: Oh, my God, I dread logging into the AWS console every time because it is such a pain in the ass. I go to cloud.google.com sometimes to check something, it's like, “Oh, right. I have to dig out my credentials.” And, “Where's my YubiKey?” And get it. Like, “Oh. I'm already log—oh. Oh, right. That's right. Google knows how identity works, and they don't actively hate their customers. Okay.” And it's always a breath of fresh air. Though I will say that by far and away, the worst login experience I've seen yet is, of course, Azure.Stephanie: [laugh]. That's exactly right. It's Google account. It's yours. It's personal. It's like an Apple iCloud account. It's one click, you're in, and you have access to all the applications. You know, so it's the same underlying identity structure with Workspace and Gmail, and it's the same org structure, too, across Workspace and Google Cloud. So, it's not just this disingenuous financial bundle between GCP and Workspace; it's really strategic. And it's kind of like the idea of low code or no code. And it looks like that's what the future of cloud will be. It's not just by VMs from us.Corey: Yeah. And there are customers who want to buy VMs and that's great. Speed up what they're doing; don't get in the way of people giving you their money, but if you're starting something net-new, there's probably better ways to do it. So, I want to thank you for taking as much time as you have to wind up going through how you think about, well, the art of storytelling in the world of engineering. If people want to learn more about who you are, what you're up to, and how you approach things, where can they find you?Stephanie: Yeah, so you can head to stephrwong.com where you can see my work and also get in touch with me if you want to collaborate on any content. I'm always, always, always open to that. And my Twitter is @stephr_wong.Corey: And we will, of course, put links to that in the [show notes 00:40:03]. Thank you so much for taking the time to speak with me.Stephanie: Thanks so much.Corey: Stephanie Wong, head of developer engagement at Google Cloud. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment telling me that the only way to get into tech these days is, in fact, to graduate with a degree from Stanford, and I can take it from you because you work in their admissions office.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Privacidad máxima con DuckDuckGo / Winamp vuelve / MediTek 9000 impacta / Marco legal para emuladores / Shinkansen operado por ordenador / Autofiltrado de cookies en Git / RPi con 48 TB Patrocinador: La gala de premios Huawei Next Image son el mayor concurso de fotografía móvil https://consumer.huawei.com/es/community/next-image/ del mundo. Más de dos millones de personas de todo el mundo han participado, y este año viene con más premios que nunca. — Las inscripciones están abiertas https://consumer.huawei.com/es/community/next-image/ hasta el 30 de noviembre, y puedes participar en múltiples categorías. Si algún lector gana que lo comparta conmigo, ¿eh? Privacidad máxima con DuckDuckGo / Winamp vuelve / MediTek 9000 impacta / Marco legal para emuladores / Shinkansen operado por ordenador / Autofiltrado de cookies en Git / RPi con 48 TB

This week's challenge: publish something.You can hear the after show and support Do By Friday on Patreon!------Edited by Quinn RoseEngineered by Cameron Bopp------Show LinksBack to Work 555: The Accretion of Non-Essential Things — Back to Work with After Dark Post-Shows — OvercastA new school board-parent battlegroundSearch - San Francisco Chronicle

Join hosts Matt, Rob and Gabor as they dig deep into Jimi Hendrix' phenomenal debut "Are You Experienced". From trippy jams to trippier liner notes, mammoth guitar tones, Beato, notable covers, killer songwriting and performances and of course, Hendrix' game-changing approach to the electric guitar.   Huge thanks to the wonderful Anthony Gerber, who has curated a Spotify playlist of every album featured on the Iconic Albums series. You rock, Anthony! GSP Iconic Albums Spotify Playlist   Rob Rhodes  www.rhodetripent.com Gabor Josika SuperFunAwesomeHappyTime Pedal Show   This episode is brought to you by Fretboard Biology    Fretboard Biology - the online guitar college created by Joe Elliott, ex Head of Guitar at GIT and McNally Smith Music College. Fretboard Biology Guitar Speak Podcast #146 - Joe Elliott - ex guitar head of GIT - launches Fretboard Biology Guitar Speak Podcast Links PayPal Tip Jar Visit us at guitarspeakpodcast.com Subscribe and find previous episodes at: Apple Podcasts Spotify Stitcher   Follow us on Facebook & Instagram   Contact us at guitarspeakpodcast@gmail.com

About Micheal BenedictMicheal Benedict leads Engineering Productivity at Pinterest. He and his team focus on developer experience, building tools and platforms for over a thousand engineers to effectively code, build, deploy and operate workloads on the cloud. Mr. Benedict has also built Infrastructure and Cloud Governance programs at Pinterest and previously, at Twitter -- focussed on managing cloud vendor relationships, infrastructure budget management, cloud migration, capacity forecasting and planning and cloud cost attribution (chargeback). Links: Pinterest: https://www.pinterest.com Twitter: https://twitter.com/micheal LinkedIn: https://www.linkedin.com/in/michealb/ 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: You know how git works right?Announcer: Sorta, kinda, not really Please ask someone else!Corey: Thats all of us. Git is how we build things, and Netlify is one of the best way I've found to build those things quickly for the web. Netlify's git based workflows mean you don't have to play slap and tickle with integrating arcane non-sense and web hooks, which are themselves about as well understood as git. Give them a try and see what folks ranging from my fake Twitter for pets startup, to global fortune 2000 companies are raving about. If you end up talking to them, because you don't have to, they get why self service is important—but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y.comCorey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Sometimes when I have conversations with guests here, we run long. Really long. And then we wind up deciding it was such a good conversation, and there's still so much more to say that we schedule a follow-up, and that's what happened today. Please welcome back Micheal Benedict, who is, as of the last time we spoke and presumably still now, the head of engineering productivity at Pinterest. Micheal, how are you?Micheal: I'm doing great, and thanks for that introduction, Corey. Thankfully, yes, I am still the head of engineering productivity; I'm really glad to speak more about it today.Corey: The last time that we spoke, we went up one side and down the other of large-scale environments running on AWS and billing aspects thereof, et cetera, et cetera. I want to stay away from that this time and instead focus on the rest of engineering productivity, which is always an interesting and possibly loaded term. So, what is productivity engineering? It sounds almost like it's an internal dev tools team, or is it something more?Micheal: Well, thanks for asking because I get this question asked a lot of times. So, for one, our primary job is to enable every developer, at least at our company, to do their best work. And we want to do this by providing them a fast, safe, and a reliable path to take any idea into production without ever worrying about the infrastructure. As you clearly know, learning anything about how AWS works—or any public cloud provider works—is a ton of investment, and we do want our product engineers, our mobile engineers, and all the other folks to be focused on delivering amazing experiences to our Pinners. So, we could be doing some of the hard work in providing those abstractions for them in such way, and taking away the pain of managing infrastructure.Corey: The challenge, of course, that I've seen is that a lot of companies take the approach of, “Ah. We're going to make AWS available to all of our engineers in it's raw, unfiltered form.” And that lasts until the first bill shows up. And then it's, “Okay. We're going to start building some guardrails around that.” Which makes a lot of sense. There then tends to be a move towards internal platforms that effectively wrap cloud services.And for a while now, I've been generally down on the concept and publicly so in the general sense. That said, what I say that applies as a best practice or something that most people should consider does tend to fall apart when we talk about specific use cases. You folks are an extremely large environment; how do you view it? First off, do you do internal platforms like that? And secondly, would you recommend that other companies do the same thing?Micheal: I think that's such a great question because every company evolves with its own pace of development. And I wouldn't say Pinterest by itself had a developer productivity or an engineering productivity organization from the get-go. I think this happens when you start realizing that your core engineers who are working on product are now spending a certain fraction of time—which starts ballooning pretty fast—in managing the underlying systems and the infrastructure. And at that point in time, it's probably a good question to ask, how can I reduce the friction in those people's lives such that they could be focused more on the product. And, kind of, centralize or provide some sort of common abstractions through a central team which can take away all that pain.So, that is generally a good guiding principle to think about when your engineers are spending at least 30% of their time on operating the systems rather than building capabilities, that's probably a good time to revisit and see whether a central team would make sense to take away some of that. And just simple examples, right? This includes upgrading OS on your EC2 machines, or just trying to make sure you're patching all the right versions on your next big Kubernetes cluster you're running for serving x number of users. The moment you start seeing that, you want to start thinking about, if there is a central team who could take away that pain, what are the things they could be investing on to help up-level every other engineer within your organization. And I think that's one of the best ways to be thinking about it.And it was also a guiding principle for us within Pinterest to view what investments we could make in these central teams which can up-level each and every different type of engineer in the company as well. And just an example on that could be your mobile engineer would have very different expectations from your backend engineer who was working on certain aspects of code in your product. And it is truly important to understand where you want to centralize capabilities, which both these types of engineers could use, or you want to divest and have unique capabilities where it's going to make them productive. There's no one-size-fits-all solution for this, but I'm happy to talk about what we have at Pinterest, which has been reasonably working well. But I do think there's a lot more improvements we could be doing.Corey: Yeah, but let's also be clear that, as you've mentioned, you are heavily biased towards EC2 instances for a lot of what you do. If we look at the AWS console and we see hundreds of different services now, and it's easy to sit here and say, “Oh, internal platforms are terrible because all of those services are going to be enhanced in various ways and you're never going to be able to keep up with feature parity.” Yeah, but if you can wrap something like EC2 in an internal platform wrapper, that begins to be a different story because sure, someone's going to go and try something new with a different AWS service, they're going to need direct access. But the EC2 product across the board generally does not evolve in leaps and bounds with transformative changes overnight. Let's also not forget that at a company with the scale that Pinterest operates at, “Hey, AWS just dusted off a new feature and docs are still rolling out, and it's not in CloudFormation yet, but we're going to roll it out to production,” probably seems like the wrong direction to go in, I would assume.Micheal: And yes, I think that brings one of the key guardrails, I think, which these groups provide. So, when we start thinking about what teams, centralized teams like engineering productivity, developer tools, developer platforms actually do is they help with a couple of things. The top three are: they can help pave a path for the most common use cases. Like to your point, provisioning EC2 does take a set of steps, all the time. If you're going to have a thousand people doing that every time they're building a new service or trying to expand capacity playing with their launch templates, those are things you can start streamlining and making it simple by some wrapper because you want to address those 80% use cases which are usually common, and you can have a wrapper or could just automate that. And that's one of the key things: can you provide a paved path for those use cases?The second thing is, can you do that by having the right guardrails in place? How often have you heard the story that, “I just clicked a button and that now spun up, like, a thousand-plus instances.” And now you have to juggle between trying to stop them or do something about it.Corey: Back in 2013, you folks were still focusing on this fair bit. I remember because Jeremy Carroll, who I believe was your first SRE there once upon a time, wound up doing a whole series of talks around how Pinterest approached doing an AMI Factory. And back in those days, the challenges were, “Okay. We have the baseline AMI, and that's great, but we also want to do deployments of things and we don't really want to do a new deploy of an entire fleet of EC2 instances for a single line of config change, so how do we wind up weighing off of when you bake a new AMI versus when you just change something that has—in what is deployed to them?” And it was really a complicated problem back then.I'm not convinced it's not still a complicated problem, but the answers are a lot more cohesive. And making sure that every team—when you're talking about a company as large as Pinterest with that many teams—is doing things in the same way, seems like it's critically important otherwise you wind up with a whole bunch of unique-looking instances that each have to be managed by hand as opposed to something that can be reasoned around collectively.Micheal: Yep. And that last part you mentioned is extremely crucial as well because like I said, our audience or our customers are just not the engineers; we do work with our product managers and business partners as well because at times, we have to tie or change our architecture based on certain cost optimizations which would make sense, like you just articulated. We don't want to have all the instance types. It does not add much value to a developer unless they're explicitly seeking a high-memory instance or a [GP-based instance in a 00:10:25] certain way. So, we can then work with our business partners to make sure that we're committing to only a certain type of instances, and how we can abstract our tools to only give you that. For example, our deployment system, Teletraan which is an open-source system, actually condenses down all these instance types to a couple of categories like high-compute, high-memory—and you've probably seen that in many of the new cloud providers as well—so people don't have to learn or know the underlying instance type.When we moved from c3 to c5, it was just called as a high-compute system, so the next time someone provisioned a new service or deployed it using our system, they would just select high-compute as the de facto instance type and we would just automatically provision a C5 for them. So, that just reduces the extra complexity or the cognitive overhead individuals would have to go through in learning each instance type, what is the base AMI that comes on it, what are the different configurations that need to go in terms of setting up your AZ-scaling properties. We give them a good reasonable set of defaults to get started with, and then they can then work on optimizing or making changes to it.Corey: Ignoring entirely your mispronunciation of AMI, which is, of course, three syllables—and that is a petty hill upon which I will die—it occurs to me the more I work with AWS in various ways, the easier it gets. And I used to think in some respects, it was because the platform was so—it was improving so dramatically around me. But no, in many cases, it's because the first time you write some CloudFormation by hand, it's a nightmare and you keep smacking into weird issues. But the second or third time, it's super easy because you just copy the thing you've already built and change the relevant bits around. And that was the learning curve that I went through playing around with a lot of these things.When you start looking at this from a large-scale environment where it's not just about upskilling the people that you have to understand how these things integrate in AWS land, but also the consistent onboarding of engineers at a fairly progressive clip is, great, you effectively have to start doing trainings on all these things, and there's a lot of knobs and dials that can blow up and hurt people. At some point, building the guardrails or building the environment in which you are getting all the stuff abstracted away from where the application engineers have to think about this at all, it eventually reaches a tipping point where it starts to feel like it's no longer optional if you want to continue growing as a company because you don't have the luxury of spending six months of onboarding before you let someone touch the thing they were hired to build.Micheal: And you will see that many companies very often have very similar programming practices like you just described. Even I learned that the same way: you have a base template, you just copy-paste it and start from there on. And no one goes through the bootstrapping process manually anymore; you want to—I think we call it cargo-culting, but in general, just get something to bootstrap and start from there. But one of the things we learned in sort of the hard way is that can also lead to, kind of, you pushing, you know, not great practices because people don't know what is a blessed version of a good template or what actually would make sense. So, some of those things, we have been working on.And this is where centralized teams like engineering productivity are really helpful is we provide you with the blessed or the canonical way to do certain things. Case in point example is a CI/CD pipeline or delivery of software services. We have invested enough in experimenting on what works with some of the more nuanced use cases at Pinterest, in helping generate, sort of, a canonical version which would cover 80% of the use cases. Someone could just go and try to build a service and they could just use the same canonical pipeline without learning much or making changes to it. This also reduces that cargo-culting nature which I called, rather than copying it from unknown sources and trying to like—again, it may cause havoc to our systems, so we can avoid a lot of that because of these practices.Corey: So, let's step a little bit beyond AWS—I know I hate doing it, too—but I'm going to assume that your remit is broader than, oh, AWS whisperer-slash-Wrangler. So, tell me a little bit more about what it is that your day-to-day looks like if there is anything that could be said not to focus purely around AWS whispering.Micheal: So, one of the challenges—and I want to talk about this a bit more—is our environments have become extremely complex over time. And it's the nature of, like, rising entropy. Like, we've just noticed that there's two things: we have a diverse set of customer base, and these include everyone trying to do different workloads or work service types. What that essentially translates into is that we realized that our solution may not fit all of them. For example, what works for a machine-learning engineer in terms of iterating on building a model and delivering a model is not the same as someone working on a long-running service and trying to deploy that. The same would apply for someone trying to operate a Kafka system.And that has made, I think, definitely our job a bit challenging in trying to assess where do you actually draw the line on the abstraction? What is the right layer of abstraction across your local development experience, across when you move over to staging your code in a PR model and getting feedback and subsequently actually releasing it to production? Because this changes dramatically based on what is the workload type you're working on. And we feel like that has been one of the biggest challenges where I know I spent my day-to-day and my team does too, in trying to help provide some of the right solutions for these individuals. There's—very often we'll also get asked from individuals trying to do a very nuanced thing.Of late, we have been talking about thinking about how you operate functions, like provide Functions as a Service within the company? It just put us in a difficult spot at times because we have to ask the hard question, “Is this required?” I know the industry is doing it; it's definitely there. I personally believe, yes, it could be a future, but is that absolutely important? Is that going to benefit Pinterest in any formal way if we invest on some core abstractions?And those are difficult conversations to have because we have exciting engineers coming in trying to do amazing things; it puts us in a hard spot, as well, as to sometimes saying graciously, no. I know many companies deal with it when they have these centralized teams, but I think it's part of that job. Like when you say it's day-to-day, I would say I'm probably saying no a couple of times in that day.Corey: Let's pretend for the sake of argument that I am, tomorrow morning, starting another company—Twitter for Pets—and over the next ten years, it grows to be larger than Pinterest in terms of infrastructure, probably not revenue because it turns out pets are not the lucrative source of ad revenue that I was hoping it would be but, you know, directionally the same thing. It seems to me that building out this sort of function with this sort of approach to things is dramatically early as far as optimizations go when it's just me puttering around on something. I'm always cognizant of the wrong people taking the wrong message when we're talking about things that happen like this at scale. When does having an engineering productivity group begin to make sense?Micheal: I mentioned this earlier; like, yeah, there is definitely not a right answer, but we can start small. For example, this group actually started more as a delivery team. You know, when we started, we realized that we had different ways of deploying services or software at Pinterest, so we first gathered together to figure out, okay, what are the different ways and can we start simplifying that part? And that's where it started expanding. Okay, we are doing button-based deployments right now we have thousand-plus microservices, and we are seeing more incidents than we wanted to because anything where there's a human involved means there's a potential gap for error. I myself was involved in a SEV 0 incident, and I will be honest; we ended up deploying a Hello World application in one of our production fleet. Not the thing I wanted to be associated with my name, but, you know—Corey: And you were suddenly saying hello to the world, in fact—Micheal: [laugh].Corey: —and oops-a-doozy.Micheal: Yeah. So—and that really prompted us to rethink how we need to enable guardrails to do safe production rollouts. And that's how those conversations start ballooning out.Corey: And the healthy correct way. We've all broken production in various ways, and it's—you correctly are identifying, I believe, the direction you're heading in where this is a process problem and a tooling problem; it is not that you are secretly crap and should never have been allowed near anything in production. I mean, that's my excuse for me, but in your case, this is a common thing where it's, if someone can unintentionally cause issues like that, there needs to be better processes and procedures as the organization matures.Micheal: Yep. And that's kind of like always the route or the starting point for these discussions. And it starts growing from there on because, okay, you've helped improve the deploy process but now we're seeing insane amount of slowness, say on the build processes, or even post-deploy, there's, like, issues on how we monitor and look into data.And that I think forces these conversations, okay, where do we have these bespoke tools available? What are people doing today? And you have to ask those hard questions, like what can we actually remove from here? The goal is not to introduce yet another new system. Many a times, to be honest bash just gets the job done. [laugh].Personally, I'm okay with that as long as it's consistent and people, you know, are able to contribute to it and you have good practices in validating it, if it works, we should go for it rather than introducing yet another YAML [laugh] and some of that other aspects of doing that work. And that's what we encourage as well. That's how I think a lot of this starts connecting together in terms of, okay, now this is becoming a productivity group; they're focused on certain challenges where investing probably one person here may up-level a few other engineers who don't have to do that on a day-to-day basis. And I think that's one of the key items for, especially, folks who are running mid-sized companies to realize and start investing in these type of teams to really up-level, sort of, the rest of the engineering.Corey: You've been doing this for a fair while. If you were to go back and start over again on day one—which is always a terrifying question, on some level—what would you have done differently about building out this function as Pinterest continued to scale out?Micheal: Well, first, I must acknowledge that this was just not me, and there's, like, ton of people involved in helping make this happen.Corey: No, that's fair. We'll blame them for the missteps; that is—Micheal: [laugh].Corey: —just fine with me. I kid. I kid.Micheal: I think, definitely the nuances. If I look back, all the decisions that were made then at that point in time, there was a decision made to move to Phabricator, which was back then a great open-source code management system where with the current information at that point in time. And I'm not—I think it's very hard to always look back and say, “Oh, we could have chosen x at one point in time.” And I think in reality, that's how engineering organizations always evolve, that you have to make do with the information you have right now to make a decision that works for you over a couple of years.And I'll give you a small example of this. There was a time when Pinterest was actually on GitHub Enterprise—this was like circa 2013, I would say—and it really served as well for, like, five-plus years. Only then at certain point, we realized that it's hard to hire PHP engineers to support a tool like that, and we had to rethink what is the ROI and the investments we've made here? Can we ever map up or match back to one of the offerings in the industry today? And that's when you make decisions that, okay, at this point in time, it's clear that business continuity talks, you know, and it's hard to operate a system, which is, at this moment not supported, and then you make a call about making a shift or moving.And I think that's the key item. I don't think there's anything dramatically I would have changed since the start. Perhaps definitely investing a bit more individuals into the group and going from there. But that said, I'm really, sort of, at least proud of the fact that usually these teams are extremely lean and small, and they always have an outsized impact, especially when they're working with other engineers, other [opinionated 00:22:13] engineers for what it's worth.This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: Most folks show up intending to do good today, and you make the best decision at the time with the context and constraints that you have, but my question I think is less around, “Well, what were the biggest mistakes you made?” But more to do with the idea of, based upon what you've learned and as you have shown—as you've shined light on these dark areas, as you have been exploring it, has anything jumped out at you that is, “Oh, yeah. Now, that I know—if I had known then what I know now, I would definitely have made this other decision.” Ideally, something that applies a little more globally than specific within Pinterest, just because the whole idea, aspirationally, is that people might learn something from our conversation. At least I will, if nothing else.Micheal: No, I think that's a great question. And I think the three things that jump to me, top of mind. I think technology is means to an end unless it gives you a competitive edge. And it's really hard to figure out at what point in time what technology and why we adopted it, it's going to make the biggest difference. Humans always tend to have a bias towards aligning towards where we want to go. So, that's the first one in my mind.The second one is, and we spoke about this last time, embrace your cloud provider as much as possible. You'd want to avoid taking on operational burden which is not going to add value to the business. If there is something you see your operating which can be offloaded—because your provider can, trust me, do a way better job than you or your team of few can ever do—embrace that as soon as possible. It's better that way because then it frees up your time to focus on the most important thing, which I've realized over time is—I really think teams like ours are actually—we're probably the most value as a glue to all the different experiences a software engineer would go through as part of their SDLC lifecycle.If we can simplify someone's life by giving them a clear view as to where their commit or the work is in this grand scheme of rolling out and giving them the right amount of data to take action when something goes wrong, trust me, they will love you for what you're doing because you're saving them ton of time. Many times, we don't realize that when we publish 11 different ways for you to go and check to just get your basic validation of work done. We tend to so much focus on the technological aspect of what the tool does, rather than the experience of it, and I've realized, if you can bridge the experience, especially for teams like ours, people really don't even need to know whether you're running Kubernetes or any of those solutions behind the scenes. And I think that's one of the biggest takeaways I have.Corey: I want to double down on something you said about the fact that you are not going to be able to run these services as effectively as your provider can. And relatively recently—in fact, since the first time we spoke—AWS has released a investment report in Virginia. And from 2011 through 2020, they have invested in building AWS data centers there, $35 billion. I promise almost no company that employs people listening to this that are not themselves a cloud provider is going to make that kind of investment in running these things themselves.Now, do cloud providers have sharp edges? Yes, absolutely. That is what my entire career is about, unfortunately. But you're not going to do a better job of running things more sustainably, more reliably, et cetera, et cetera. But there are other problems with this—and that's what I want to start exploring here—where in the olden days, when I ran things in data centers and they went down a lot more as a result, sometimes when there were outages, I would have the CEO of the company just standing there nervous worrying over my shoulder as I frantically typed to fix things.Spoiler: my typing accuracy did not improve by having someone looming over me. Now, when there's an outage that your cloud provider takes, in many cases the thing that you are doing to fix it is reloading the status page and waiting for an update because it is completely out of your hands. Is that something that you've had to encounter? Because you can push buttons and turn dials when things are broken and you control it, but in an AWS—or other cloud provider—outage, all you can really do is wait unless you have a DR plan that is large-scale and effective enough that you won't feel foolish or have wasted a huge amount of time and energy migrating off and then—because then it gets repaired in ten minutes. How do you approach that, from your perspective? I guess, the expectation management piece?Micheal: It's definitely I know something which keeps a lot of folks within infrastructure up at night because, like you just said, at times we can feel extremely powerless when we obviously don't have direct control—or visibility at times, as well—on what's happening. One of the things we have realized over time as part of running on our cloud provider for over a decade now, it forces us to rethink a bit on our priority workflows, what we want our Pinners to always have access to, what they need to see, what is not important or critical. Because it puts into perspective, even for the infrastructure teams, is to what is the most important thing we should always have it available and running, what is okay to be in a degraded state, until what time, right? So, it actually forces us to define SLOs and availability criteria within the team where we can broadcast that to the larger audience including the executives. So, none of this comes as a surprise at that point.I mean, it's not the answer, probably, you're looking for because is there's nothing we can do except set expectations clearly on what we can do and how when you think about the business when these things do happen. So, I know people may have I have a different view on this; I'm definitely curious to hear as well, but I know at Pinterest at least we have converged on our priority workflows. When something goes out, how do we jump in to provide a degraded experience? We have very clear run books to do that, and especially when it's a SEV 0, we do have clear processes in place on how often we need to update our entire company on where things are. And especially this is where your partnership with the cloud provider is going to be a big, big boon because you really want to know or have visibility, at the minimum some predictability on when things can get resolved, and how you want to work with them on some creative solutions. This is outside the DR strategy, obviously; you should still be focused on a DR strategy, but these are just simple things we've learned over time on how to just make it predictable for individuals within the company, so not everyone is freaking out.Corey: Yeah, from my perspective, I think the big things that I found that have worked, in my experience—mostly by getting them wrong the first time—is explain that someone else running the infrastructure when they take an outage; there's not much we can do. And no, it's not the sort of thing where picking up the phone and screaming at someone is going to help us, is the sort of thing that is best to communicate to executive stakeholders when things are running well, not in the middle of that incident.Then when things break, it's one of those, “Great, you're an exec. You know what your job is? Literally anything other than standing in the middle of the engineering floor, making everyone freak out even more. We'll have a discussion later about what the contributing factors were when you demand that we fire someone because of an outage. Then we're going to have a long and hard talk about what kind of culture you're trying to build here again?” But there are no perfect answers here.It's easy to sit here in the silver light of day with things working correctly and say, “Oh, yeah. This is how outages should be handled.” But then when it goes down, we're all basically an inch away at best from running around with our hair on fire, screaming, “Fix it, fix it, fix it, fix it, now.” And I am empathetic to that. There's a reason but I fix AWS bills for a living, and one of those big reasons is that it's a strictly business-hours problem and I don't have to run production infrastructure that faces anything that people care about, which is kind of amazing and freeing for someone who spent too many years on call.Micheal: Absolutely. And one of the things is that this is not only with the cloud provider, I think in today's nature of how our businesses are set up, there's probably tons of other APIs you are using or you're working with you may not be aware of. And we ended up finding that the hard way as well. There were a certain set of APIs or services we were using in the critical path which we were not aware of. When these outages happen, that's when you find that out.So, you're not only beholden to your provider at that point in time; you have to have those SLO expectations set with your other SaaS providers as well, other folks you're working with. Because I don't think that's going to change; it's probably only going to get complicated with all the different types of tools you're using. And then that's a trade-off you need to really think about. An example here is just like—you know, like I said, we moved in the past from GitHub to Phabricator—I didn't close the loop on that because we're moving back to GitHub right now [laugh] and that's one of the key projects I'm working with. Yeah, it's circle of life.But the thing is, we did a very strong evaluation here because we felt like, “Okay, there's a probability that GitHub can go down and that means people will be not productive for that couple of hours. What do we do then?” And we had to put a plan together to how we can mitigate that part and really build that confidence with the engineering teams, internally. And it's not the best solution out there; the other solution was just run our own, but how is that going to make any other difference because we do have libraries being pulled out of GitHub and so many other aspects of our systems which are unknowingly dependent on it anyways. So, you have to still mitigate those issues at some point in your entire SDLC process.So, that was just one example I shared, but it's not always on the cloud provider; I think there are just many aspects of—at least today how businesses are run, you're dependent; you have critical dependencies, probably, on some SaaS provider you haven't really vetted or evaluated. You will find out when they go down.Corey: So, I don't think I've told this story before, but before I started this place, I was doing a fair bit of consulting work for other companies. And I was doing a project at Pinterest years ago. And this was one of the best things I've ever experienced at a company site, let alone a client site, where I was there early in the morning, eight o'clock or so, so you know, engineers love to show up at the crack of 11:30. But so I was working a little early; it was great. And suddenly my SSH session that I was using to remote into something or other hung.And it's tap up, tap enter a couple of times, tap it a couple more. It was hung hard. “What's the—” and then someone gently taps me on the shoulder. So, I take the headphones off. It was someone from corporate IT was coming around saying, “Hey, there's a slight problem with our corporate firewall that we're fixing. Here's a MiFi device just for you that you can tether to get back online and get worked on until the firewall gets back.”And it was incredible, just the level of just being on top of things, and the focus on keeping the people who were building things and doing expensive engineering work that was awesome—and also me—productive during that time frame was just something I hadn't really seen before. It really made me think about the value of where do you remove bottlenecks from people getting their jobs done? It was—it remains one of the most impressive things I've seen.Micheal: That is great. And as you were telling me that I did look up our [laugh] internal system to see whether a user called Corey Quinn existed, and I should confirm this with you. I do see entries over here, a couple of commits, but this was 2015. Was that the time you were around, or is this before that even?Corey: That would have been around then, yes. I didn't start this place until late 2016.Micheal: I do see your commits, like, from 2015, and I—Corey: And they're probably terrible, I have no doubt. There's a reason I don't read code for a living anymore.Micheal: Okay, I do see a lot of GIFs—and I hope it's pronounced as GIF—okay, this is cool. We should definitely have a chat about this separately, Corey?Corey: Oh, yeah. “Would you explain this code?” “Absolutely not. I wrote it. Of course, I have no idea what it does. That's the rule. That's the way code always works.”Micheal: Oh, you are an honorary Pinterest engineer at this point, and you have—yes—contributed to our API service and a couple of Puppet profiles I see over here.Corey: Oh, yes—Micheal: [Amazing 00:36:11]. [laugh].Corey: You don't wind up thinking that's a risk factor that should be disclosed. I kid. I kid. It's, I made a joke about this when VMware acquired SaltStack and I did some analytics and found that 60 some odd lines of code I had written, way back when that were still in the current version of what was being shipped. And they thought, “Wait, is this actually a risk?”And no, I am making a joke. The joke is, is my code is bad. Fortunately, there are smart people around me who review these things. This is why code review is so important. But there was a lot to admire when I was there doing various things at Pinterest. It was a fun environment to work in, the level of professionalism was phenomenal, and I was just a big fan of a lot of the automation stuff.Phabricator was great. I love working with it, and, “Great, I'm going to use this to the next place I go.” And I did and then it was—I looked at what it took to get it up and running, and oh, yeah, I can see why GitHub is so popular these days. But it was neat. It was interesting seeing that type of environment up close.Micheal: That is great to hear. You know, this is what I enjoy, like, hearing some of these war stories. I am surprised; you seem to have committed way more than I've ever done in my [laugh] duration here at Pinterest. I do managing for a living, but then again—Corey, the good news is your code is still running on production. And we—Corey: Oh dear.Micheal: —haven't—[laugh]. We haven't removed or made any changes to it, so that's pretty amazing. And thank you for all your contributions.Corey: Oh, please, you don't have to thank me. I was paid, it was fine. That's the value of—Micheal: [laugh].Corey: —[work 00:37:38] for hire. It's kind of amazing. And the best part about consultants is, is when we're done with a project, we get the hell out everyone's happy about it.More happy when it's me that's leaving because of obvious personality-related reasons. But it was just an interesting company from start to finish. I remember one other time, I wound up opening a ticket about having a slight challenge with a flickering on my then Apple-branded display that everyone was using before they discontinued those. And I expected there to be, “Oh, okay. You're a consultant. Great. How did we not put you in the closet with a printer next to that thing, breathing the toner?” Like most consulting clients tend to do, and sure enough, three minutes later, I'm getting that tap on the shoulder again; they have a whole replacement monitor. “Can you go grab a cup of coffee? We'll run the cable for it. It'll just be about five minutes.” I started to feel actively bad about requesting things because I did a lot of consulting work for a lot of different companies, and not to be unkind, but treating consultants and contractors super well is not something that a lot of companies optimize for. I can't necessarily blame them for that. It just really stood out.Micheal: Yep, I do hope we are keeping up with that right now because I know our team definitely has a lot of consultants working with us as well. And it's always amazing to see; we do want to treat them as FTs. It doesn't even matter at that point because we're all individuals and we're trying to work towards common goals. Like you just said, I think I personally have learned a few items as well from some of these folks. Which is again, I think speaks to how we want to work and create a culture of, like, we're all engineers; we want to be solving problems together, and as you were doing it, we want to do it in such a way that it's still fun, and we're not having the restrictions of titles or roles and other pieces. But I think I digressed. It was really fun to see your commits though, I do want to track this at some point before we move completely over to GitHub, at least keep this as a record, for what it's worth.Corey: Yeah basically look at this graffiti in the codebase of, “A shit-poster was here,” and here I am. And that tends to be, on some level, the mark we live on the universe. What's always terrifying is looking at things I did 15 years ago in my first Linux admin job. Can I still ping the thing that I built there? Yes, I can. And how is that even possible? That should not have outlived me; honestly, it should never have seen the light of day in production, but here we are. And you never know how long that temporary kluge you put together is going to last.Micheal: You know, one of the things I was recalling, I was talking to someone in my team about this topic as well. We always talk about 10x engineers. I don't know what your thoughts are on that, but the fact that you just mentioned you built something; it still pings. And there's a bunch of things, in my mind, when you are writing code or you're working on some projects, the fact that it can outlast you and live on, I think that's a big, big contribution. And secondly, if your code can actually help up-level, like, ten other people, I think you've really made the mark of 10x engineer at that point.Corey: Yeah, the idea of the superhuman engineer is always been a strange and dangerous one. If for nothing else, from where I sit, excellence is inherently situational. Like we just talked about someone at Pinterest: is potentially going to be able to have that kind of impact specifically because—to my worldview—that there's enough process and things around there that empower them to succeed. Then if you were to take that engineer and drop them into a five-person startup where none of those things exist, they might very well flounder. It's why I'm always a little suspicious of this is a startup founded by engineers from Google or Facebook, or wherever it is.It's, yeah, and what aspects of that culture do you think are one-to-one matches with the small scrappy startup in the garage? Right, I predicting some challenges here. Excellence is always situational. An amazing employee at one company can get fired at a second one for lack of performance, and that does not mean that there's anything wrong with them and it does not mean that they are a fraud. It means that what they needed to be successful was present in one of those shops, but not the other.Micheal: This is so true. And I really appreciate you bringing this up because whenever we discuss any form of performance management, that is a—in my view personally—I think that's an incorrect term to be using. It is really at that point in time, either you have outlived the environment you are in, or the environment is going in a different direction where I think your current skill set probably could be best used in the environment where it's going to work. And I know it's very fuzzy at that point, but like you said, yes, excellence really means you don't want to tie it to the number of commits you have pushed out, or any specific aspect of your deliverables or how you work.Corey: There are no easy answers to any of these things, and it's always situational. It's why I think people are sometimes surprised when I will make comments about the general case of how things should be, then I talk to a specific environment where they do the exact opposite, and I don't yell at them for it. It's there—in a general sense, I have some guidance, but they are usually reasons things are the way they are, and I'm interested in hearing them out. Everything's situational, the worst consultant in the world is the one that shows up, has no idea what's going on, and then asked, “What moron set this up?” Invariably, two said, quote-unquote, “Moron.” And the engagement doesn't go super well from there. It's, “Okay, why is this the way that it is? What constraints shaped it? What was the context behind the problem you were trying to solve?” And, “Well, why didn't you use this AWS service?” “Because it didn't exist for another three years when we were building that thing,” is a—Micheal: Yes.Corey: —common answer.Micheal: Yes, you should definitely appreciate that of all the decisions that have been made in past. People tend to always forget why they were made. You're absolutely right; what worked back then will probably not work now, or vice versa, and it's always situational. So, I think I can go on about this for hours, but I think you hit that to the point, Corey.Corey: Yeah, I do my best. I want to thank you for taking another block of time out of your day to wind up talking with me about various aspects of what it takes to effectively achieve better levels of engineering productivity at large companies, with many teams, working on shared codebases. If people want to learn more about what you're up to, where can they find you?Micheal: I'm definitely on Twitter. So, please note that I'm spelled M-I-C-H-E-A-L on Twitter. So, you can definitely read on to my tweets there. But otherwise, you can always reach out to me on LinkedIn, too.Corey: Fantastic and we will, of course, include a link to that in the [show notes 00:44:02]. Thanks once again for your time. I appreciate it.Micheal: Thanks a lot, Corey.Corey: Micheal Benedict, head of engineering productivity at Pinterest. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a comment telling me that you work at Pinterest, have looked at the codebase, and would very much like a refund and an apology.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

About Guang Ming Guang Ming Whitley was elected to Mount Pleasant Town Council in 2017 and resides in Old Mount Pleasant with her husband, four children, and a dog.She earned a B.S. in Chemical Engineering from the University of Southern California and a J.D. from the University of Chicago Law School, where she was a member of Law Review and a moot court semi-finalist. After completing her law degree, Guang Ming taught at the University of Chicago and practiced intellectual property law in Los Angeles. She then retired from active practice to serve as Chief Operating Officer of the Whitley Household. In 2020, she cofounded Lattice Climbers, a company dedicated to teaching soft and life skills to young adults.Guang Ming is also President of the Girls State Alumnae Foundation and attended the American Legion Auxiliary Girls State in 1996, where she was elected governor. She has volunteered with the ALA Girls State program in a variety of capacities since 2000.Links:Lattice Climbers: https://www.latticeclimbers.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate: is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards, while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other, which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at Honeycomb.io/screaminginthecloud. Observability, it's more than just hipster monitoring.Corey: You know how git works right?Announcer: Sorta, kinda, not really Please ask someone else!Corey: Thats all of us. Git is how we build things, and Netlify is one of the best way I've found to build those things quickly for the web. Netlify's git based workflows mean you don't have to play slap and tickle with integrating arcane non-sense and web hooks, which are themselves about as well understood as git. Give them a try and see what folks ranging from my fake Twitter for pets startup, to global fortune 2000 companies are raving about. If you end up talking to them, because you don't have to, they get why self service is important—but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y.comCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Sometimes people like to ask me what this show is really about and my answer has always been, “The business of cloud,” which is intentionally overbroad; really gives me an excuse to talk about anything that strikes my fancy at a given time. A recurring theme has always been, “Where does the next generation of folks working on cloud come from?”That's not strictly bounded to engineers; that goes throughout the entire ecosystem. There are a lot of jobs that are important to the functioning of businesses that don't require a whole bunch of typing into a text editor and being mad about YAML all day long. Today, my guest is Guang Ming Whitley. Guang Ming, thank you for joining me, I'll let you tell the story. Who are you exactly?Guang Ming: Oh, my goodness. That's a tough question. Well, I am someone who has lived my life in a series of segments. I started off as an engineer—a chemical engineer—then went off to law school, taught for a year—Corey: Well, let's interject as well. That is how I got looped into this whole nonsense; you were law school classmates with my spouse. And whatever you're in town, she gets very excited at the chance to see you, and we finally got to meet not that long ago, had a great conversation. It was, “Oh, my God, you need to come on the podcast.” Which is neither here nor there. Please, continue.Guang Ming: So, then I had a segment as a stay-at-home mother. I started having babies and I had a lot of them. I had one daughter, then a son, and then I had identical twin boys. And once I started having them in litters, we decided that it was time to stop. So, four kids in and about a decade as a stay-at-home mom, during which time I wrote some books.And then ran for office back in 2017. And then in 2020, was working with someone just, kind of, over coffee, just having, you know, conversation, and we came up with the idea to start a business, and Lattice Climbers was born out of that.Corey: And Lattice Climbers is what I think we're going to be talking about the most today because there's an entire episode baked into every one of those steps. Maybe not every one of them would fit on a cloud-oriented podcast, but there's a lot of interesting backstory there and it resonates with me because my entire life has been lived in phases as well. And the more I talk to people, the more I start to realize that maybe I'm not that bizarre. People go through stages and they'd love to retcon what the story was at the time and make it all look like there's a common thread and narrative running through, but when we're going through it, it feels—to me at least—like I've been careening from thing to thing to thing without ever really having an end goal in mind. But in hindsight, looking back, it just seems like it was inevitable that I would go from where I was to here. It never feels that way at the time for me.Guang Ming: Well, I think for me, where I've ended up with Lattice Climbers has felt sort of inevitable because one of the through-lines of all my segments that I've gone through is a program called Girls State, and it is one that I have volunteered with. It's sponsored by the American Legion Auxiliary and it's a government simulation program. Over the course of one week, you simulate city, county, and state government. And it's all about civic engagement and education of young women, and empowerment. So, it's such a fantastic program.And I love it, but one of the things that I've seen with this program is, as the young women come through the program, some of them have skills, and some of them don't have skills. And there's elements that are missing, and that's something that I want to try to help with, with Lattice Climbers.Corey: So, what is Lattice Climbers in a nutshell? It's still very early days, which is fine, terrific; the fact that you care enough about a problem that is clearly plaguing not just our industry, but arguably our entire society is worth exploring in-depth. And with the understanding that the narrative may very well shift as times go on what is Lattice Climbers today?Guang Ming: So, Lattice Climbers steps into the gap between formal education and the skills necessary to actually adult at life, to survive in the real world.Corey: That is an area that is of intense interest to me. For listeners who may not have listened to every single episode here, my academic background is checkered, to put it politely. On paper, I have an eighth-grade education and no one can take that away from me. I was expelled from two boarding schools in high school, I wound up getting a diploma from a homeschooling organization that years later I discovered was not accredited, then I failed out of college. But again, no one can take that eighth-grade education away from me.But also look at me. I am a white dude in tech where my failure mode is a board seat and a book deal somewhere, and there are winds of privilege at my back when I do that. What also has been a strong contributing factor is that when I was 12 years old, my dad sat me down and had a long conversation with me about how to handle a job interview, what a job interview was—because when I was 12, I had no idea—and what they're looking to gain from asking you these questions, and why they're asking you the things that they do, what answers they're looking for, and the purpose behind the meeting that you're in. And that more than almost anything else as a single moment in my childhood shaped the reason that I became moderately successful [laugh] in my career, depending on what phase of my career we're talking about. That's stuff is super important and they don't teach it formally in any program I've ever seen. How do you approach it?Guang Ming: So, what we do is we have an intake quiz that assesses your skill gaps, sort of like a self-assessment, and then it gives you a customized curriculum just meant to fill your specific skill gaps. So professionalism, where we cover things like interview skills, behavior at events, table manners, those kinds of things. Financial literacy, we have little mantras like, “Credit cards are not free money,” [laugh] which some people never learned that. And then there's different tracks, so depending on whether or not you're college-bound, or vocational school, or military-bound, you can pick a different track for that and receive two-minute lessons, sort of the gems, distilled down. And there's little animations; we try to keep it as brief and information-packed as possible.Corey: Would it be fair to categorize this as more or less micro-lessons in how to adult?Guang Ming: Exactly. That is exactly what we're trying to do.Corey: I somewhat recently read one of the best stories I've ever heard about teaching students in middle school about financial literacy. And invariably, the financial literacy courses are all sponsored by financial institutions, and that's great. So, what happened was, someone from the bank came in and spoke to the students and then took them all to the bank and had them all open a bank account and deposit $5 into it. Great. A couple of years go by and it earns interest—not much because $5—the bank was then acquired and acquired again and eventually became rolled into Wells Fargo, and had a small balance fee, which then of course wiped out all of these accounts.And I don't think that there is any better lesson in the way the financial system works—in some ways—than that. And yes, that's cynical, but that idea of, if you are sort of toward the bottom, this system is basically stacked against you in a bunch of different ways. Look, I'm not here to rail against capitalism or society as it stands, but understanding that basic concept is foundational to realizing that maybe the credit card company isn't always your friend with your very best interests in mind.Guang Ming: Mm-hm. And we tried to explain that, too, you that when you get a credit limit, that is based on what your ability to pay the minimum balance every month. They don't care if you can pay it off. They care about making that interest off of you, and I think that's something that children and young adults need to understand.Corey: It feels like it ties into the idea of thinking critically. The problem with that is the root of that entire financial literacy anecdote that I came out with just now, is that the financial literacy program was developed and promoted by financial institutions. What I like is that I checked your website very briefly, and given the significant absence of a pile of disclosures at the bottom, I don't believe you're a bank.Guang Ming: We are not a bank, and we are not sponsored by a bank. We want to provide practical real-life advice that is useful, and in digestible chunks.Corey: A while back, before I wound up starting down the path that I'm on now, I basically yelled at people for fun on the internet. I know, imagine that. I was the moderator of two particular subreddits: personal finance—which, great, I spent my 20s in crippling debt; there's no one as passionate about that stuff as someone who has been converted. Great. And the other was the legal advice subreddit, which is probably horrifying to people like you who are actual attorneys.But it turns out that an awful lot of what I was doing in both of those subreddits was giving life advice to people on how to function in society. On the legal side of it, “You can't sue a dog.” “Okay, you are not going to be able to go down to the police station and explain your way out of troubles. Get an attorney.” It's baseline-level stuff.“Oh, you've been given a contract that seems unreasonable, but they'd say that you need you to sign it.” “Yeah. How about don't do that without having someone review it?” It's not actually legal advice. It is how to function in society as an adult, but that's a less catchy subreddit title as it turns out.Guang Ming: Well, it's all about raising your awareness level. So, I have a friend and she tells this story, MBA grad and spent her first six months on the job wearing sneakers every day to work—they were cute, fashionable sneakers, but they were sneakers—and they were not part of appropriate business attire for the work environment she was in because she just was oblivious to that as being an issue. And it took someone who was more senior to finally sit her down and say, “You shouldn't do this. You need to wear appropriate shoes to work.” And she was mortified but learned from that experience.So, what if you never had to have that? What if you never had to have that sit-down conversation with someone correcting you? What if you had a little, sort of, pocket guide that gave you that level of awareness? It's like, “Take a look at your office. See what people are wearing. You can't wear what the CEO is wearing because you're not the CEO”—I mean, unless you are the CEO, then you can wear whatever you want, but if you're just an underling at the company, if you're just starting out, you need to understand what the company culture is and you need to conform to that culture. Unfortunately, that's just, like… the truth of the matter.Corey: The common wisdom is, “Oh, if you don't know how to dress or how to behave in a certain scenario, reach out to one of your mentors and ask them for advice.” Not everyone has one of those things. I get some crap sometimes through it, but one of the big reasons I have open DMs on Twitter is specifically so people can message me and ask me questions about the industry generally, life in general; I'm always willing to talk to folks who are trying to figure things out. That's important. Since a disproportionate number of the listeners to this show do work in tech and the idea of having a dress code is ridiculous, yeah, in a lot of tech culture at t-shirt and jeans is just fine, but in other cases, it's not.And, for example, I'll get on stage wearing a full bespoke three-piece suit and give a talk. And it's fun. It's hilarious. It plays with people's expectations, but it's important to understand I view that more as costuming than I do how I believe someone should necessarily dress in that environment. I am, for better or worse, a very distinctive personality in this space, and using me as a blueprint for someone who is starting out their career is going to lead to disaster.Yes, I'm mouthy and I make fun of big companies because that's my thing. I also got fired an awful lot in—Guang Ming: [laugh].Corey: —my career, and those two things are not entirely unrelated, let's be very clear here. There's a lot that we can learn through observation, but dialing it in and figuring out what the expectations, are important.Guang Ming: Well, I think a lot of young adults—one of the things we focus on, as well, is the importance of mentoring and finding good mentors. And then you being the kind of person that a mentor would want to mentor. Because I think there's a lot of formal mentoring in work environments, and those don't always work as well as the organic relationships. So, we want to be that mentor that you never knew that you needed, the mentor that you wish you always had, to give you all that baseline information so that when you do meet with your substantive mentor, they can truly help you in ways that we cannot with our scalable mentoring micro-lessons.Corey: I have to ask, what is your revenue model? Because if this turns into charging kids money to learning these things, that has a giant exploitative flashing warning sign around it.Guang Ming: So, what we're planning to do is work with school districts and with nonprofits, and do sort of like a B2B model where we pilot with the school district, we pilot with the technical college, and give them an opportunity to add 30 to 50 students, work with the program. And if they find it something valuable, they find that it's a value-add and it's helping their students land jobs and have a better career, I think that then they'll use our program for their full technical school.Corey: I'm done a fair number of mentorships in the course of my career. I helped administer and run the LOPSA 00:13:43—or League Of Professional System Administrators—mentorship program for a couple of years. The reason that I have a career at all is that people did favors for me, and you can never repay that; you can only pay it forward. So, I had a number of people assigned to me through that program and through other areas as well, and what I've learned is that the success of a mentorship is almost entirely on the person seeking guidance: how diligent are they about following up, about going and asking great questions? Because otherwise, if someone comes and says, “Hey, can you mentor me?”—they never frame it quite like that, but that's fine; the terminology is always squishy here.Like, “Hey, can you give me advice on things?” “Sure.” And then they don't ask any questions. Well, if I just butt in with unsolicited advice, that's not helping them in a mentoring capacity; that's being a dude on Twitter. So, I'm trying to figure out the way of solving for that, and I don't know if there is an answer. What's your take?Guang Ming: I think that for many young people, there is a baseline level of information that they need, that almost any mentor can give, but it takes up a lot of time to get to that point. So, for example, I had a young woman reach out to me, and she wanted to get a foot in the door in the legal world and wanted some advice. And I couldn't. It was like, pulling teeth. I couldn't get her to say a word about herself. And our conversation lasted less than five minutes because I couldn't get her to speak about herself.And I almost let it end at that. But then I circled back with her a week later, and called her and said, “You know, I'm going to connect you to someone because I want to help you in your journey. But I need you to think before you get to that conversation about who you are, what you want, where you're going, what's your story. You know, I know just from the person who connected us that you're the first in your family to go to college. Speak to that.” And just really tried to help her understand that she needed to craft a narrative around herself. And I think a lot of young adults don't know how to craft that narrative.Corey: The problem that I see when I look at this systemically is that all of this stuff seems like it's very bespoke. It's [spreading an 00:15:45] opportunity, but it is incumbent upon folks to learn about it for themselves. One of the most foundational memories of my ill-fated academic career was in public school for my first sophomore year of high school, where the US history teacher said, all right. Today, we're not doing our traditional stuff, what I'm about to do is not in the curriculum. Please feel free to complain to your parents and then have them take it to the school board.And what he did was he passed at a flyer where each one of us had different numbers on it, and it was a, “You are a family of x number of people; you made this much money last year.” And then he passed out 1040-EZ forms. And he taught us how to file a tax return in the course of that 45-minute session. And it was, instead of learning a series of whitewashed facts about American history, I was learning how to function as an adult in society. And the fact that he had to do this almost as a subversive thing as opposed to being an accepted part of the curriculum is just mind-boggling to me. I see what you're doing is important and valuable, but it also in some level kind of feels like a band-aid over a massive societal failing. Is that accurate or am I missing something?Guang Ming: No, I think that certain school districts are trying to do this, they're trying to integrate financial literacy into calculus. Some schools will even offer a course, but the course isn't an AP course; it doesn't give you special credit, and so students don't take it, or it's viewed as a less valuable course even though it's probably the most valuable course. And there's also a level of embarrassment. Like, for certain things, we cover personal hygiene. The importance of brushing your teeth every day, and taking a shower, and wearing deodorant.Which is something you wouldn't necessarily think you would need to teach someone, but wait till you're in certain work environments, and that is actually something that people need to know that they're bothering their coworkers by this lack. That can be really embarrassing.With Lattice Climbers, you can do this in the privacy of your own home, you can do it in your bedroom, you can do it wherever you are, and you can get these little lessons and not feel embarrassed. Or sometimes you are afraid to ask a question because you feel dumb asking it. When we did a pilot with 17-to 19-year-olds, the favorite video was actually making an appointment. Just giving tips on how to gather the appropriate documentation you would need to, say for example, make a doctor's appointment, and sample scripts—we have downloadables that go along with—sample scripts of how a conversation would potentially run if you were to call.Corey: The way you describe this and the problem you're solving, I have a hard time seeing this as the business opportunity that becomes a $60 billion company because to do that, you would have to do something that is abjectly terrifying. So apparently, becoming rich beyond the wildest dreams of avarice is not the reason that you're doing this. What made you decide that this was a problem you wanted to address?Guang Ming: So, I am the daughter of an immigrant and a first-generation college student. And there were so many things that my parents just didn't know to teach me. They were very focused on academics and there was no focus on anything outside of book smarts. So, when I had my first college interview, my mom took me to the Fashion for Price Boutique next to the Drug Emporium in the strip mall near our home and bought me an interview suit—we didn't have a ton of money—and the interview suit involved zebra print zippers and a very short skirt. And that is what I wore to my Harvard interview. The one [laugh] school I didn't get into.And not only that, not only was I dressed wholly inappropriately, I also was a deer in the headlights. I had never done a mock interview, I had never done anything that would help prepare me for this situation. And I look back at that 17-year-old and I think, “How can I help her? How can I help people like her who don't have the social or cultural capital to know these things, to know how to move in the world that they want to be in desperately? How do I help them overcome that obstacle?” And that is how Lattice Climbers was born.Corey: The idea of having an experience like that as being necessary to forge this is—it's moving. It's the sort of thing that you hear about other people—you [unintelligible 00:20:04] secondhand cringing from hearing that sort of story, at least I do. And I can definitely understand not wanting other folks to have to go through this. We talk about hilarious interview mistakes that we've made, that we've had candidates make, and in some cases, most of the ones that I like to talk about are the folks who are—let's [unintelligible 00:20:23] here—25 years into their career or so, where they really should know better. Because making fun of some naive kid who'd never been in an interview scenario before is just being shitty, let's be clear.At some point, though, you should learn how to comport yourself in a working environment that makes sense. But without having mentorships or guidance like that, it feels like a lot of people have stories like this. I think what makes your story different than most of them is that you're willing to talk about it in public. Most of us bury those things down the memory hole, I would think.Guang Ming: Yes. I very much own the zebra print story, and it is something that I share when I speak at Girls State. I speak at Girls State just about every year to the young women, and I talk a lot about some of these things that we go over in Lattice Climbers to just try to impart, even in a six-minute speech, some of the key nuggets that I want them to take away with them, as they move through life.Corey: Tell me a little more about Girls State. I've heard the term a couple of times, but know remarkably little about it because, for better or worse, my daughters are still at a point where—I regret this constantly—I have to know entirely too much about the Paw Patrol.Guang Ming: So, Girls Day is a program sponsored by the American Legion Auxiliary. It is a week-long civic engagement program that simulates government over the course of one week. And for California Girls State, it is one girl from each sponsored high school, with about 540 young women—and of course, we've had to be virtual for the past couple of years, but they've done it in a webinar virtual sessions—and the program is all about women empowerment and encouraging civic engagement. And one of the things that has really impacted Lattice Climbers has been my observations in Girls State as a counselor for over 20 years. Because we work with young women from all different backgrounds, whether their parents are migrant workers in Modesto or doctors in Big Sur, there are gaps that these young women have that differ based on their backgrounds.And what I'm hoping to do with Lattice Climbers is fill those gaps and help them avoid these missteps and increase their trajectory as they climb the lattice. And that is one thing that we do is we don't talk about climbing the ladder because a ladder implies that there is one pathway to the top, there's room for only one there. We approach it as you're climbing a lattice: we're all in it together and there are infinite paths to success.Corey: All of these things that you talk about are challenging at the best of times, and these are very clearly not the best of times. One of the reasons that, to date, we at The Duckbill Group have not hired junior folks is because in a full-remote environment—and to be clear, even without the pandemic The Duckbill Group has been full-remote since its inception—I don't know that's necessarily the best way to expose someone new to the workforce. It feels to me like there's not a lot of examples around there. There's a requirement to be a lot more self-directed, and it's likely, for example, that someone will get stuck and spin on something for a while rather than asking for help because they don't want to appear like they don't know what they're doing and inadvertently make things worse. Do you think that remote as we move forward is going to be an increasing burden on folks like this, or—which I'm perfectly willing to accept—am I completely wrong, and that in fact having a full-remote environment like this is in fact a terrific opportunity for folks new to the workforce?Guang Ming: No, I think full-remote is an issue. I think that it takes so much more emotional energy to connect through a video than it does to connect in person. And there's also the lack of organic interactions. There are so many mentorships that develop just from walking down the hall and running into someone over coffee, or at the wat—I mean literally at the watercooler and having the opportunity to chat with someone about something non-work-related that can then evolve into a mentoring relationship. And there is just a lack of that.All these young people entering the work environment, they can wear pajamas all day and lay in bed with their laptop on their laps and work, and they may love that, but I think that if you want to work in a professional office environment, you need to understand appropriate attire, you need to understand appropriate behavior at events. I think that, especially if you're from certain backgrounds and you've never been around an open buffet before, it can be very tempting to just pile that plate as high as you can with crab legs or, you know, shrimp cocktail. And it's not appropriate in that setting. And so we cover those—Corey: Wait. It's not?Guang Ming: [laugh]. Well, it depe—if you're the CEO of the company, Corey, you can do whatever you want.Corey: No, no. That's my business partner. I am just the chief cloud economist because it's not professional to put the word shit-poster on a business card. Or so they tell me.Guang Ming: [laugh].Corey: In my experience, the worst of all worlds, though, is not the full-remote; it's not the in-office; it's the hybrid scenario where you have some people that are in an office together working and then you have folks who are remote, and regardless of what your intentions are, it is almost impossible to avoid having a striated structure where the in-person folks collaborate in different ways and make decisions informally to which remote folks are not privy. And it's not to do with cliques or anything like that, but the watercooler discussions, or, “I'm going to go grab lunch. Do you want to come with me?” Type of engagement stories. And I can't shake the feeling that remote really needs to be all or nothing, at least within the bounds of a team, if not company-wide.Guang Ming: I think that a hybrid version could work if there was a concerted effort to include the remote individuals if there was a scheduled Zoom happy hour. So, one of the things that happened during the COVID times is there's a group that I'm a part of, and we just had a happy hour on Saturday nights. At 8 p.m. everyone just kind of logged on and hung out for a period of time. And it was really good to connect with people in that casual environment; there wasn't always pressure to speak, there wasn't always pressure to perform, it was just being together and having that togetherness. So, I think that in a work environment, you could create opportunities for that. And then also, I think, bringing people into the office for specific meetings and things that are important like that. And then potentially—I don't like assigning mentors, but I think you almost have to assign mentors when you have remote workforce.Corey: This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals. Having the highest quality content in tech and cloud skills, and building a good community the is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. Its both useful for individuals and large enterprises, but here's what makes it new. I don't use that term lightly. Cloud Academy invites you to showcase just how good your AWS skills are. For the next four weeks you'll have a chance to prove yourself. Compete in four unique lab challenges, where they'll be awarding more than $2000 in cash and prizes. I'm not kidding, first place is a thousand bucks. Pre-register for the first challenge now, one that I picked out myself on Amazon SNS image resizing, by visiting cloudacademy.com/corey. C-O-R-E-Y. That's cloudacademy.com/corey. We're gonna have some fun with this one!Corey: The challenge also becomes one of, great for junior folks, that makes an awful lot of sense. Hire someone with 15 years of experience, and, “Oh, we're going to assign you a mentor here.” And they're like, “Oh, really. So, that's what condescending means. I was always looking for a perfect example.”Guang Ming: [laugh].Corey: That's a delicate balance to strike in my experience.Guang Ming: Oh, very true. Very true. I was thinking more of, like, the young adults starting out in their career because our focus is really early career, as well as young adults in high school.Corey: And that's, I guess, my question for you next is why is that the target age range that you think is best served by this? Now, having, again, spent too much time gazing into the mess that is the Paw Patrol, I understand why preschoolers are not the target market for this, but my approach has generally been targeting folks who are entering the workforce. Although let's be very clear, a large part of that is because I generally don't appreciate the optics of going and hanging out at the local high school trying to talk to kids.Guang Ming: Well, I think that high school is really where it starts. This is the age at which brains are starting to develop a little bit more; they're starting to have more social awareness. This is where beginnings of your network are important. And I think that the sooner that we can convey to young people that they're only as strong as their networks, the better. If they can understand that it's their teachers, their coaches, the parents of their friends are all the beginnings of their network.That's how you get internships, that's how you get a leg up is through these connections because if you're just a resume floating out there, your chances of getting looked at—and we all know how the world works—well, we should all know how the world works, which is it's all about your connections that helps you launch to the next thing.Corey: That's the thing that I think is understated in this is that we wind up telling students a whole bunch of things that are well-intentioned lies. The, “Oh, put your nose to the grindstone and work hard, and one day you will surely be promoted.” Now, I get flack when I say this sometimes from folks who've been at the same company for 15 years and demonstrated growth trajectory internally, but that's the exception, not the rule. Big moves generally look a lot like transitioning between companies.“Oh, you don't want to be a job hopper. It looks bad on the resume.” Yeah, you know who says that? People who don't want you to quit your job because you're unhappy because then they have to backfill you, or people who are trying to recruit you in and want to make sure that you when you show up at this new job, you stay there for a while. It's self-serving.Yeah, there's going to be some questions about it in the interview process, but you should have an answer ready to go for it. It's the interview skills piece of it and make sure that you don't inadvertently torpedo your own candidacy with conversations like that. And this is stuff that I find that is—it's not just the newer generation that we're talking about here; people well into their careers still haven't cracked a lot of these codes, mostly because, for better or worse, it turns out that people aren't nearly as cynical [laugh] about things as I am.Guang Ming: Well, and we also cover things like how to leave a job professionally. Because as we live in a world where you're not going to go work for one company for the next 30 years, or where you shouldn't go work for the same company for 30 years necessarily, but there are stories out there of people just ghosting on the job, ghosting on job interviews, and that burns bridges. And everyone you meet is a potential connection in your network as you climb the lattice, and so you need to preserve those relationships moving forward because you never know who you help out along the way, or who helps you out along the way, you never know how that connection is going to play out later on in life.Corey: That's the trick is that it's talking to people and being friendly with them. And there are ways to do networking properly in my world, and there are ways not to. And, “Oh, I should talk to you because down the road you might be useful to me,” is just cynical and terrible. I hate the pattern.Whereas, I like keeping in touch with people because I find them interesting. My default assumption has always been that I'm going to be talking to someone for longer than either one of us is going to be doing whatever it is we're currently doing, and trying to treat relationships as transactional is a mistake. But that's what networking is often interpreted as.Guang Ming: It's so true. And people can tell. They can tell when you're being fake. They can tell when you're being transactional. They can tell when you just are waiting for the ask.I think it actually is really hard to be genuine and natural for some people that comes across as transactional, and one of the ways that we talked about avoiding that is through just an ongoing relationship. So, you don't only reach out to the person when you have an ask, you reach out to the person quarterly. And you can have a spreadsheet—almost—about it, and of the people that you want to contact and maintain cont—and even if it's just a text message that says, “Hey, this is what I'm up to. Hope all is well with you.” And even if they don't respond, or just it's a one-word answer, you've at least had that touchpoint with them over the course of time.Corey: There's often a criticism levied at folks who are advocating for networking, that it is a lot harder when you're an introvert or when you are neurodivergent, in certain ways. To be clear, I've neurodivergent in ways that do not directly negatively impact my ability to socialize with folks; it just means they think I'm a jerk. But there are folks who definitely have different expressions of different divergences. And that's fine. How do you view the networking aspect for folks who do not work nearly as well interpersonally?Guang Ming: That's so hard because interpersonal skills are something that is so necessary, and I think that unfortunately, there are people who get by one hundred percent on their social skills. Like, their people skills are all they need to move forward in the world. And I think that you have to work at it, and you have to study how to behave in those situations. It's almost like—so for example, my husband is an introvert, but he was also an actor in college. And when he goes into these situations, it's almost like putting on a show.Like you talked about putting on your three-piece suit. There is the extrovert persona that he wears in these environments, and then he takes it off when he gets home. And I think that you almost have to create that persona for yourself. And you can acknowledge that you're neurodivergent, and you can acknowledge that you're an introvert, and I think that's way more acceptable these days than it used to be. And there are lots of people that are in the world that are neurodivergent and are introverts, and so I think it's completely fine to be that way.Corey: I've never had a good answer for folks who ask those questions, just because it is so different from my lived experience that I don't have an answer that's worth listening to, and I try very hard to stay in my lane. I don't ever want that to be interpreted as it's not important because it very much is.So, one last question I have for you is I love, love, love your zebra print suit story, but it's also back when you were applying to school, back in early career, which you are very clearly not now; it's decades old. Do you have any other similar stories from folks that you've been working through, either at Lattice Climbers or through Girls State, that illustrate this in a somewhat more modern era?Guang Ming: Oh, absolutely. So, there was a young woman at Girls State; we were all in a room and they were talking about colleges, the girls were talking about colleges. And this one young woman remains silent during this conversation. And so I approached her. I said, “Well, what about you? What are your plans for college?” And she shared that she wasn't going to go to college because her parents didn't go to college, they didn't have a lot of money, and she just didn't think that college was in the cards for her.And I disabused her of that notion. I told her absolutely not. You're here at Girls State, which means you're the top girl from your high school. You absolutely should go to college, and I told her that there were so many paths to college. You could go to community college and then transfer; you could go to technical college; there's so many different options.And there's so many scholarships out there, especially for low-income individuals. Well, we became friends on social media, and about three years after Girls State—because they attend the summer after their junior years—I received a message from her, sort of, out of the blue, and she let me know that that conversation that we had changed her life because she had gone to community college—she had taken my advice; she had gone to community college and had just been accepted as a transfer student to UC Berkeley. And that story just makes me tear up every time I think about it. And that one conversation had that huge impact on her life, and I'm hoping that through Lattice Climbers and our little lessons, that we can have that kind of impact on young lives, that we can help them avoid these missteps that could have huge impacts on their trajectory, and we could help them increase their trajectory on the lattice.Corey: It's similar in some respects to the folks I talk to who are building products for the cloud industry. It's, “Yes, yes, of course. You're always going to have a story about how it works for you. That's fine. Let's talk about your customers.” Like, “Find me a customer, someone else in the world who has a story like this that really demonstrates the value you provide.”And I love the fact that it is so easy for you to come up with these things off the top of your head, even when you weren't necessarily expecting the question. So, you're onto something. This is a clear problem, and it's not going away anytime soon, and it's largely underserved because there's no opportunity to invest venture capital into it and make a ridiculous return on that investment because there's not money in solving it that I can see—and apparently, most the industry can see—compared to another Twitter for Pets app.Guang Ming: [laugh]. Well, there is not that much money in them there hills because no one owns the problem, and because no one owns the problem, it's very hard to find people willing to pay to solve the problem. But that doesn't mean that the problem isn't there and that doesn't mean that it doesn't need to be solved. And I actually think that companies should have an incentive to do it because it will help with employee retention, it will help with employee performance if they do invest in their workers, and in high school students who, the sooner that they know these things, the better it will be for their long-term careers.Corey: And if nothing else, I think that's the lesson to take away from this for the young folk—the youth, as it were—that this is the single greatest thing I look at and credit my professional trajectory has been in learning to handle expectations in corporate environments. And sure, I have fun with them and I play games with them, but you have to know the rules before you can break them in this context. And there are business meetings in which I assure you, you would question whether it was the same person. And that's what it comes down to, I think, on some level is, if you know how to handle a job interview, you will always be able to find something to put food on the table. Conversely, if you're terrific at any number of different things, but absolutely cannot handle the dynamics of a job interview, you are going to struggle to find work anywhere until you find someone willing to alter their corporate process just in order to bring you aboard.It's a skill that you need to be at least conversant with. And what makes it even worse, as it's a skill that you only really get to practice when you're looking for jobs. I want to thank you for taking the time to speak with me so much about all this stuff. If people want to learn more about what you're up to and how you're approaching it, where can they find you?Guang Ming: So, we are at latticeclimbers.com. And we are currently in waitlist mode, so you can sign up on our waitlist and get more information about when we're ready to launch. We are working with some nonprofits and some school districts on some pilot programs, and we're hoping to have that going, hopefully by the end of the year.Corey: And we will, of course, put a link to that in the [show notes 00:38:07]. Thank you so much for taking the time to speak with me today. I really appreciate it.Guang Ming: Well, thank you so much for having me. I really appreciate the opportunity to share what we're doing with Lattice Climbers, and I just hope, like I said, if I can get one person to not wear zebra print to that Harvard interview, [laugh] then I will view Lattice Climbers as a success.Corey: [laugh]. Excellent. Thank you so much. Once again, Guang Ming Whitley, co-founder of Lattice Climbers. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, along with a rambling comment explaining why we're wrong and that a zebra-print suit for a college interview is in fact a best practice.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Mordy Oberstein joins the JavaScript Jabber panel to discuss SEO and how what seems like a marketing concern is relevant and exciting for developers. SEO is working with a black box with regards to Google since Google and other search engines don't tell you anything about how they adjust their search algorithms. Mordy walks through how developers can contribute to the issues around showing up in search engine results. Panel AJ O'NealDan ShappirSteve Edwards Guest Mordy Oberstein Sponsors Shortcut (formerly Clubhouse.io)Raygun | Click here to get started on your free 14-day trialTop End Devs Links The Best SEO Podcast for Tips & InsightsMordy Oberstein - Facebook Picks AJ- Better off Ted - Jabberwocky Project - YouTubeAJ- Rise of the RobotsAJ- The Economic SingularityAJ- Dangerous Wrongthinkers ( AlignPay and 2nd Amendment Processing )AJ- Creeds of CraftsmanshipDan- Google Is The Most Searched Word On BingDan- Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes - YouTubeMordy- For All Mankind | Apple TV+Steve- Best Practices (why I Hate Them)Steve- The wholly pun bible - InstagramSteve- Dad Jokes by Pubity - Instagram Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode )coolaj86- Twitch Contact Dan: GitHub: Dan Shappir ( DanShappir )LinkedIn: Dan ShappirTwitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards Special Guest: Mordy Oberstein.

Mordy Oberstein joins the JavaScript Jabber panel to discuss SEO and how what seems like a marketing concern is relevant and exciting for developers. SEO is working with a black box with regards to Google since Google and other search engines don't tell you anything about how they adjust their search algorithms. Mordy walks through how developers can contribute to the issues around showing up in search engine results. Panel AJ O'NealDan ShappirSteve Edwards Guest Mordy Oberstein Sponsors Shortcut (formerly Clubhouse.io)Raygun | Click here to get started on your free 14-day trialTop End Devs Links The Best SEO Podcast for Tips & InsightsMordy Oberstein - Facebook Picks AJ- Better off Ted - Jabberwocky Project - YouTubeAJ- Rise of the RobotsAJ- The Economic SingularityAJ- Dangerous Wrongthinkers ( AlignPay and 2nd Amendment Processing )AJ- Creeds of CraftsmanshipDan- Google Is The Most Searched Word On BingDan- Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes - YouTubeMordy- For All Mankind | Apple TV+Steve- Best Practices (why I Hate Them)Steve- The wholly pun bible - InstagramSteve- Dad Jokes by Pubity - Instagram Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode )coolaj86- Twitch Contact Dan: GitHub: Dan Shappir ( DanShappir )LinkedIn: Dan ShappirTwitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards Special Guest: Mordy Oberstein.

The application process for a job in software development or software engineering typically involves what's known as a "technical interview." Technical interviews are notorious for being intimidating and exclusionary of otherwise good candidates. Technical interviews may involve whiteboarding, live coding, brain teasers, or even take-home projects. In this episode we'll explain what these different kinds of technical interviews are like and why they induce so much fear. We'll also discuss the bias inherent in these interviews, their pros and cons versus the alternatives, and how to best prepare for them. Show Notes Episode 62: What is an Algorithm? Episode 61: What is a Data Structure? Episode 57: Version Control Systems, Git, and GitHub HackerRank LeetCode Cracking the Coding Interview via Amazon Follow us on Twitter @KopecExplains. Theme “Place on Fire” Copyright 2019 Creo, CC BY 4.0 Find out more at http://kopec.live

About RichardHe's also an instructor at Pluralsight, a frequent public speaker, and the author of multiple books on software design and development. Richard maintains a regularly updated blog (seroter.com) on topics of architecture and solution design and can be found on Twitter as @rseroter. Links: Twitter: https://twitter.com/rseroter LinkedIn: https://www.linkedin.com/in/seroter Seroter.com: https://seroter.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: You know how git works right?Announcer: Sorta, kinda, not really Please ask someone else!Corey: Thats all of us. Git is how we build things, and Netlify is one of the best way I've found to build those things quickly for the web. Netlify's git based workflows mean you don't have to play slap and tickle with integrating arcane non-sense and web hooks, which are themselves about as well understood as git. Give them a try and see what folks ranging from my fake Twitter for pets startup, to global fortune 2000 companies are raving about. If you end up talking to them, because you don't have to, they get why self service is important—but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y.comCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Once upon a time back in the days of VH1, which was like MTV except it played music videos, would have a show that was, “Where are they now?” Looking at former celebrities. I will not use the term washed up because that's going to be insulting to my guest.Richard Seroter is a returning guest here on Screaming in the Cloud. We spoke to him a year ago when he was brand new in his role at Google as director of outbound product management. At that point, he basically had stars in his eyes and was aspirational around everything he wanted to achieve. And now it's a year later and he has clearly failed because it's Google. So, outbound products are clearly the things that they are going to be deprecating, and in the past year, I am unaware of a single Google Cloud product that has been outright deprecated. Richard, thank you for joining me, and what do you have to say for yourself?Richard: Yeah, “Where are they now?” I feel like I'm the Leif Garrett of cloud here, joining you. So yes, I'm still here, I'm still alive. A little grayer after twelve months in, but happy to be here chatting cloud, chatting whatever else with you.Corey: I joke a little bit about, “Oh, Google winds up killing things.” And let's be clear, your consumer division which, you know, Google is prone to that. And understanding a company's org chart is a challenge. A year or two ago, I was of the opinion that I didn't need to know anything about Google Cloud because it would probably be deprecated before I really had to know about it. My opinion has evolved considerably based upon a number of things I'm seeing from Google.Let's be clear here, I'm not saying this to shine you on or anything like that; it's instead that I've seen some interesting things coming out of Google that I consider to be the right moves. One example of that is publicly signing multiple ten-year deals with very large, serious institutions like Deutsche Bank, and others. Okay, you don't generally sign contracts with companies of that scale and intend not to live up to them. You're hiring Forrest Brazeal as your head of content for Google Cloud, which is not something you should do lightly, and not something that is a short-term play in any respect. And the customer experience has continued to improve; Google Cloud products have not gotten worse, and I'm seeing in my own customer conversations that discussions about Google Cloud have become significantly less dismissive than they were over the past year. Please go ahead and claim credit for all of that.Richard: Yeah. I mean, the changes a year ago when I joined. So, Thomas Kurian has made a huge impact on some of that. You saw us launch the enterprise APIs thing a while back, which was, “Hey, here's, for the most part, every one of our products that has a fixed API. We're not going to deprecate it without a year's notice, whatever it is. We're not going to make certain types of changes.” Maybe that feels like, “Well, you should have had that before.” All right, all we can do is improve things moving forward. So, I think that was a good change.Corey: Oh, I agree. I think that was a great thing to do. You had something like 80-some-odd percent coverage of Google Cloud services, and great, that's going to only increase with time, I can imagine. But I got a little pushback from a few Googlers for not being more congratulatory towards them for doing this, and look, it's a great thing. Don't get me wrong, but you don't exactly get a whole lot of bonus points and kudos and positive press coverage—not that I'm press—for doing the thing you should have been doing [laugh] all along.It's, “This is great. This is necessary.” And it demonstrates a clear awareness that there was—rightly or wrongly—a perception issue around the platform's longevity and that you've gone significantly out of your way to wind up addressing that in ways that go far beyond just yelling at people on Twitter they don't understand the true philosophy of Google Cloud, which is the right thing to do.Richard: Yeah, I mean, as you mentioned, look, the consumer side is very experimental in a lot of cases. I still mourn Google Reader. Like, those things don't matter—Corey: As do we all.Richard: Of course. So, I get that. Google Cloud—and of course we have the same cultural thing, but at the same time, there's a lifecycle management that's different in Google Cloud. We do not deprecate products that much. You know, enterprises make decade-long bets. I can't be swap—changing databases or just turning off messaging things. Instead, we're building a core set of things and making them better.So, I like the fact that we have a pretty stable portfolio that keeps getting a little bit bigger. Not crazy bigger; I like that we're not just throwing everything out there saying, “Rock on.” We have some opinions. But I think that's been a positive trend, customers seem to like that we're making these long-term bets. We're not going anywhere for a long time and our earnings quarter after quarter shows it—boy, this will actually be a profitable business pretty soon.Corey: Oh, yeah. People love to make hay, and by people, I stretch the term slightly and talk about, “Investment analysts say that Google Cloud is terrible because at your last annual report you're losing something like $5 billion a year on Google Cloud.” And everyone looked at me strangely, when I said, “No, this is terrific. What that means is that they're investing in the platform.” Because let's be clear, folks at Google tend to be intelligent, by and large, or at least intelligent enough that they're not going to start selling cloud services for less than it costs to run them.So yeah, it is clearly an investment in the platform and growth of it. The only way it should be turning a profit at this point is if there's no more room to invest that money back into growing the platform, given your market position. I think that's a terrific thing, and I'm not worried at all about it losing money. I don't think anyone should be.Richard: Yeah, I mean, strategically, look, this doesn't have to be the same type of moneymaker that even some other clouds have to be to their portfolio. Look, this is an important part, but you look at those ten-year deals that we've been signing: when you look at Univision, that's a YouTube partnership; you look at Ford that had to do with Android Auto; you look at these others, this is where us being also a consumer and enterprise SaaS company is interesting because this isn't just who's cranking out the best IaaS. I mean, that can be boring stuff over time. It's like, who's actually doing the stuff that maybe makes a traditional company more interesting because they partner on some of those SaaS services. So, those are the sorts of deals and those sorts of arrangements where cloud needs to be awesome, and successful, and make money, doesn't need to be the biggest revenue generator for Google.Corey: So, when we first started talking, you were newly minted as a director of outbound product management. And now, you are not the only one, there are apparently 60 of you there, and I'm no closer to understanding what the role encompasses. What is your remit? Where do you start? Where do you stop?Richard: Yeah, that's a good question. So, there's outbound product management teams, mostly associated with the portfolio area. So network, storage, AI, analytics, database, compute, application modernization-y sort of stuff—which is what I cover—containers, dev tools, serverless. Basically, I am helping make sure the market understands the product and the product understands the market. And not to be totally glib, but a lot of that is, we are amplification.I'm amplifying product out to market, analysts, field people, partners: “Do you understand this thing? Can I help you put this in context?” But then really importantly, I'm trying to help make sure we're also amplifying the market back to our product teams. You're getting real customer feedback: “Do you know what that analyst thinks? Have you heard what happened in the competitive space?”And so sometimes companies seem to miss that, and PMs poke their head up when I'm about to plan a product or I'm about to launch a product because I need some feedback. But keeping that constant pulse on the market, on customers, on what's going on, I think that can be a secret weapon. I'm not sure everybody does that.Corey: Spending as much time as I do on bills, admittedly AWS bills, but this is a pattern that tends to unfold across every provider I've seen. The keynotes are chock-full of awesome managed service announcements, things that are effectively turnkey at further up the stack levels, but the bills invariably look a lot more like, yeah, we spend a bit of money on that and then we run 10,000 virtual instances in a particular environment and we just treat it like it's an extension of our data center. And that's not exciting; that's not fun, quote-unquote, but it's absolutely what customers are doing and I'm not going to sit here and tell them that they're wrong for doing it. That is the hallmark of a terrible consultant of, “I don't understand why you're doing what you're doing, so it must be foolish.” How about you stop and gain some context into why customers do the things that they do?Richard: No, I send around a goofy newsletter every week to a thousand or two people, just on things I'm learning from the field, from customers, trying to make sure we're just thinking bigger. A couple of weeks ago, I wrote an idea about modernization is awesome, and I love when people upgrade their software. By the way, most people migration is a heck of a lot easier than if I can just get this into your cloud, yeah love that; that's not the most interesting thing, to move VMs around, but most people in their budget, don't have time to rewrite every Java app to go. Everybody's not changing .NET framework to .NET core.Like, who do I think everybody is? No, I just need to try to get some incremental value first. Yes, then hopefully I'll swap out my self-managed SQL database for a Spanner or a managed service. Of course, I want all of that, but this idea that I can turn my line of business loan processing app into a thousand functions overnight is goofy. So, how are we instead thinking more pragmatically about migration, and then modernizing some of it? But even that sort of mindset, look, Google thinks about innovation modernization first. So, also just trying to help us take a step back and go, “Gosh, what is the normal path? Well, it's a lot of migration first, some modernization, and then there's some steady-state work there.”Corey: One of the things that surprised me the most about Google Cloud in the market, across the board, has been the enthusiastic uptake for enterprise workloads. And by enterprise workloads, I'm talking about things like SAP HANA is doing a whole bunch of deployments there; we're talking Big Iron-style enterprise-y things that, let's be honest, countervene most of the philosophy that Google has always held and espoused publicly, at least on conference stages, about how software should be built. And I thought that would cut against them and make it very difficult for you folks to gain headway in that market and I could not have been more wrong. I'm talking to large enterprises who are enthusiastically talking about Google Cloud. I've got a level with you, compared to a year or two ago, I don't recognize the place.Richard: Mmm. I mean, some of that, honestly, in the conversations I have, and whatever I do a handful of customer calls every week, I think folks still want something familiar, but you're looking for maybe a further step on some of it. And that means, like, yes, is everybody going to offer VMs? Yeah, of course. Is everyone going to have MySQL? Obviously.But if I'm an enterprise and I'm doing these generational bets, can I cheat a little bit, and maybe if I partner with a more of an innovation partner versus maybe just the easy next step, am I buying some more relevance for the long-term? So, am I getting into environment that has some really cool native zero-trust stuff? Am I getting into environment with global backend services and I'm not just stitching together a bunch of regional stuff? How can I cheat by using a more innovation vendor versus just lifting and shifting to what feels like hosted software in another cloud? I'm seeing more of that because these migrations are tough; nobody should be just randomly switching clouds. That's insane.So, can I make, maybe, one of these big bets with somebody who feels like they might actually even improve my business as a whole because I can work with Google Pay and improve how I do mobile payments, or I could do something here with Android? Or, heck, all my developers are using Angular and Flutter; aren't I going to get some benefit from working with Google? So, we're seeing that, kind of, add-on effect of, “Maybe this is a place not just to host my VMs, but to take a generational leap.”Corey: And I think that you're positioning yourselves in a way to do it. Again, talk about things that you wouldn't have expected to come out of Google of all places, but your console experience has been first-rate and has been for a while. The developer experience is awesome; I don't need to learn the intricacies of 12 different services for what I'm trying to do just in order to get something basic up and running. I can stop all the random little billing things in my experimental project with a single click, which that admittedly has a confirm, which you kind of want. But it lets you reason about these things.It lets you get started building something, and there's a consistency and cohesiveness to the console that, again, I am not a graphic designer, by any stretch of the imagination. My most commonly used user interface is a green-screen shell prompt, and then I'm using Vim to wind up writing something horrifying, ideally in Python, but more often in YAML. And that has been my experience, but just clicking around the console, it's clear that there was significant thought put into the design, the user experience, and the way of approaching folks who are starting to look very different, from a user persona perspective.Richard: I can—I mean, I love our user research team; they're actually fun to hang out with and watch what they do, but you have to remember, Google as a company, I don't know, cloud is the first thing we had to sell. Did have to sell Gmail. I remember 15 years ago, people were waiting for invites. And who buys Maps or who buys YouTube? For the most part, we've had to build things that were naturally interesting and easy-to-use because otherwise, you would just switch to anything else because everything was free.So, some of that does infuse Google Cloud, “Let's just make this really easy to use. And let's just make sure that, maybe, you don't hate yourself when you're done jumping into a shell from the middle of the console.” It's like, that should be really easy to do—or upgrade a database, or make changes to things. So, I think some of the things we've learned from the consumer good side, have made their way to how we think of UX and design because maybe this stuff shouldn't be terrible.Corey: There's a trope going around, where I wound up talking about the next million cloud customers. And I'm going to have to write a sequel to it because it turns out that I've made a fundamental error, in that I've accepted the narrative that all of the large cloud vendors are pushing, to the point where I heard from so many folks I just accepted it unthinkingly and uncritically, and that's not what I should be doing. And we'll get to what I was wrong about in a minute, but the thinking goes that the next big growth area is large enterprises, specifically around corporate IT. And those are folks who are used to managing things in a GUI environment—which is fine—and clicking around in web apps. Now, it's easy to sit here on our high horse and say, “Oh, you should learn to write code,” or YAML, which is basically code. Cool.As an individual, I agree, someone should because as soon as they do that, they are now able to go out and take that skill to a more lucrative role. The company then has to backfill someone into the role that they just got promoted out of, and the company still has that dependency. And you cannot succeed in that market with a philosophy of, “Oh, you built something in the console. Now, throw it away and do it right.” Because that is maddening to that user persona. Rightfully so.I'm not that user persona and I find it maddening when I have to keep tripping over that particular thing. How did that come to be, from your perspective? First, do you think that is where the next million cloud customers come from? And have I adequately captured that user persona, or am I completely often the weeds somewhere?Richard: I mean, I shared your post internally when that one came out because that resonated with me of how we were thinking about it. Again, it's easy to think about the cloud-native operators, it's Spotify doing something amazing, or this team at Twitter doing something, or whatever. And it's not even to be disparaging. Like, look, I spent five years in enterprise IT and I was surrounded by operators who had to run dozen different systems; they weren't dedicated to just this thing or that. So, what are the tools that make my life easy?A lot of software just comes with UIs for quick install and upgrades, and how does that logic translate to this cloud world? I think that stuff does matter. How are you meeting these people a little better where they are? I think the hard part that we will always have in every cloud provider is—I think you've said this in different forums, but how do I not sometimes rub the data center on my cloud or vice versa? I also don't want to change the experience so much where I degrade it over the long term, I've actually somehow done something worse.So, can I meet those people where they are? Can we pull some of those experiences in, but not accidentally do something that kind of messes up the cloud experience? I mean, that's a fine line to walk. Does that make sense to you? Do you see where there's a… I don't know, you could accidentally cater to a certain audience too much, and change the experience for the worse?Corey: Yes, and no. My philosophy on it is that you have to meet customers where they are, but only to a point. At some point, what they're asking for becomes actively harmful or disadvantageous to wind up providing for them. “I want you to run my data center for me,” is on some level what some cloud environments look like, and I'm not going to sit here and tell people they're inherently wrong for that. Their big reason for moving to the cloud was because they keep screwing up replacing failed hard drives in their data center, so we're going to put it in the cloud.Is it more expensive that way? Well, sure in terms of actual cash outlay, it almost certainly is, but they're also not going down every month when a drive fails, so once the value of that? It's a capability story. That becomes interesting to me, and I think that trying to sit here in isolation, and say that, “Oh, this application is not how we would build it at Google.” And it's, “Yeah, you're Google. They are insert an entire universe of different industries that look nothing whatsoever like Google.” The constraints are different, the resources are different, and—Richard: Sure.Corey: —their approach to problem-solving are different. When you built out Google, and even when you're building out Google Cloud, look at some of the oldest craftiest stuff you have in your entire all of Google environment, and then remember that there are companies out there that are hundreds of years old. It's a different order of magnitude as far as era, as far as understanding of what's in the environment, and that's okay. It's a very broad and very diverse world.Richard: Yeah. I mean, that's, again, why I've been thinking more about migration than even some of the modernization piece. Should you bring your network architecture from on-prem to the cloud? I mean, I think most cases, no. But I understand sometimes that edge firewall, internal trust model you had on-prem, okay, trying to replicate that.So, yeah, like you say, I want to meet people where they are. Can we at least find some strategic leverage points to upgrade aspects of things as you get to a cloud, to save you from yourself in some places because all of a sudden, you have ten regions and you only had one data center before. So, many more rooms for mistakes. Where are the right guardrails? We're probably more opinionated than others at Google Cloud.I don't really apologize for that completely, but I understand. I mean, I think we've loosened up a lot more than maybe people [laugh] would have thought a few years ago, from being hyper-opinionated on how you run software.Corey: I will actually push back a bit on the idea that you should not replicate your on-premises data center in your cloud environment. Sure, are there more optimal ways to do it that are arguably more secure? Absolutely. But a common failure mode in moving from data center to cloud is, “All right, we're going to start embracing this entirely new cloud networking paradigm.” And it is confusing, and your team that knows how the data center network works really well are suddenly in way over their heads, and they're inadvertently exposing things they don't intend to or causing issues.The hard part is always people, not technology. So, when I glance at an environment and see things like that, perfect example, are there more optimal ways to do it? Oh, from a technology perspective, absolutely. How many engineers are working on that? What's their skill set? What's their position on all this? What else are they working on? Because you're never going to find a team of folks who are world-class experts in every cloud? It doesn't work that way.Richard: No doubt. No doubt, you're right. There's areas where we have to at least have something that's going to look similar, let you replicate aspects of it. I think it's—it'll just be interesting to watch, and I have enough conversations with customers who do ask, “Hey, where are the places we should make certain changes as we evolve?” And maybe they are tactical, and they're not going to be the big strategic redesign their entire thing. But it is good to see people not just trying to shovel everything from one place to the next.Corey: This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals. Having the highest quality content in tech and cloud skills, and building a good community the is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. Its both useful for individuals and large enterprises, but here's what makes it new. I don't use that term lightly. Cloud Academy invites you to showcase just how good your AWS skills are. For the next four weeks you'll have a chance to prove yourself. Compete in four unique lab challenges, where they'll be awarding more than $2000 in cash and prizes. I'm not kidding, first place is a thousand bucks. Pre-register for the first challenge now, one that I picked out myself on Amazon SNS image resizing, by visiting cloudacademy.com/corey. C-O-R-E-Y. That's cloudacademy.com/corey. We're gonna have some fun with this one!Corey: Now, to follow up on what I was saying earlier, what I think I've gotten wrong by accepting the industry talking points on is that the next million cloud customers are big enterprises moving from data centers into the cloud. There's money there, don't get me wrong, but there is a larger opportunity in empowering the creation of companies in your environment. And this is what certain large competitors of yours get very wrong, where it's we're going to launch a whole bunch of different services that you get to build yourself from popsicle sticks. Great. That is not useful.But companies that are trying to do interesting things, or people who want to found companies to do interesting things, want something that looks a lot more turnkey. If you are going to be building cloud offerings, that for example, are terrific building blocks for SaaS companies, then it behooves you to do actual investments, rather than just a generic credit offer, into spurring the creation of those types of companies. If you want to build a company that does payroll systems, in a SaaS, cloud way, “Partner with us. Do it here. We will give you a bunch of credits. We will introduce you to your first ten prospective customers.”And effectively actually invest in a company success, as opposed to pitch-deck invest, which is, “Yeah, we'll give you some discounting and some credits, and that's our quote-unquote, ‘investment.'” actually be there with them as a partner. And that's going to take years for folks to wrap their heads around, but I feel like that is the opportunity that is significantly larger, even than the embedded existing IT space because rather than fighting each other for slices of the pie, I'm much more interested in expanding that pie overall. One of my favorite questions to get asked because I think it is so profoundly missing the point is, “Do you think it's possible for Google to go from number three to number two,” or whatever the number happens to be at some point, and my honest, considered answer is, “Who gives a shit?” Because number three, or number five, or number twelve—it doesn't matter to me—is still how many hundreds of billions of dollars in the fullness of time. Let's be real for a minute here; the total addressable market is expanding faster than any cloud or clouds are going to be able to capture all of.Richard: Yeah. Hey, look, whoever who'll be more profitable solving user problems, I really don't care about the final revenue number. I can be the number one cloud tomorrow by making Google Cloud free. What's the point? That's not a sustainable business. So, if you're just going for who can deploy the most VCPUs or who can deploy the most whatever, there's ways to game that. I want to make sure we are just uniquely solving problems better than anybody else.Corey: Sorry, forgive me. I just sort of zoned out for a second there because I'm just so taken aback and shocked by the idea of someone working at a large cloud provider who expresses a philosophy that isn't lying awake at night fretting over the possibility of someone who isn't them as making money somewhere.Richard: [laugh]. I mean, your idea there, it'll be interesting to watch, kind of, the maker's approach of are you enabling that next round of startups, the next round of people who want to take—I mean, honestly, I like the things we're doing building block-wise, even with our AI: we're not just handing you a vision API, we're giving you a loan processing AI that can process certain types of docs, that more packaged version of AI. Same with healthcare, same with whatever. I can imagine certain startups or a company idea going, “Hey, maybe I could disrupt or serve a new market.”I always love what Square did. They've disrupted emerging markets, small merchants here in North America, wherever, where I didn't need a big expensive point of sale system. You just gave me the nice, right building blocks to disrupt and run my business. Maybe Google Cloud can continue to provide better building blocks, but I do like your idea of actually investment zones, getting part of this. Maybe the next million users are founders and it's not just getting into some of these companies with, frankly, 10, 20, 30,000 people in IT.I think there's still plenty of room in these big enterprises to unlock many more of those companies, much more of their business. But to your point, there's a giant market here that we're not all grabbing yet. For crying out loud, there's tons of opportunity out here. This is not zero-sum.Corey: Take it a step further beyond that, and today, if you have someone who's enterprising, early on in their career, maybe they just got out of school, maybe they have just left their job and are ready to snap, or they have some severance money that they want to throw into something. Great. What do they want to do if they have an idea for a company? Well today, that answer looks a lot like, well, time to go to a boot camp and learn to code for six months so you can build a badly done MVP well enough to get off the ground and get some outside investment, and then go from there. Well, what if we cut that part out entirely?What if there were building blocks of I don't need to know or care that there's a database behind it, or what a database looks like. Picture Visual Basic in a web browser for building apps, and just take this bit of information I give you and store it and give it back to me later. Sure, you're going to have some significant challenges in the architecture or something like that as it goes from this thing that I'm talking about as an MVP to something planet-scale—like a Spotify for example—but that's not most businesses, and that's okay. Get out of the way and let people innovate and iterate on what it is they're doing more rapidly, and make it more accessible to teach people. That becomes huge; that gets the infrastructure bits that cloud providers excel at out of the way, and all it really takes is packaging those things into a golden path of what a given company of a particular profile should be doing, if—unless they have reason to deviate from it—and instead of having this giant paradox of choice issue, it's, “Oh, okay, I'll drag-drop, build things accordingly.”And under the hood, it's doing all the configuration of services and that's great. But suddenly, you've made being a founder of a software company—fundamentally—accessible to people who are not themselves software engineers. And I know that's anathema to some people, and I don't even slightly care because I am done with gatekeeping.Richard: Yeah. No, it's exciting if that can pull off. I mean, it's not the years ago where, how much capital was required to find the rack and do all sorts of things with tech, and hire some developers. And it's an amazing time to be software creators, now. The more we can enable that—yeah, I'm along for that journey, sign me up.Corey: I'm looking forward to seeing how it winds up shaking out. So, I want to talk a little bit about the paradox of choice problem that I just mentioned. If you take a look at the various compute services that every cloud provider offers, there are an awful lot of different choices as far as what you can run. There's the VM model, there's containers—if you're in AWS, you have 17 ways to run those—and you wind up—any of the serverless function story, and other things here and there, and managed services, I mean and honestly, Google has a lot of them, nowhere near as many as you do failed messaging products, but still, an awful lot of compute options. How do customers decide?What is the decision criteria that you see? Because the worst answer you can give someone who doesn't really know what they're doing is, “It depends,” because people don't know how to make that decision. It's, “What factors should I consider then, while making that decision?” And the answer has to be something somewhat authoritative because otherwise, they're going to go on the internet and get yelled at by everyone because no one is ever going to agree on this, except that everyone else is wrong.Richard: Mm-hm. Yeah, I mean, on one hand, look, I like that we intentionally have fewer choices than others because I don't think you need 17 ways to run a container. I think that's excessive. I think more than five is probably excessive because as a customer, what is the trade-off? Now, I would argue first off, I don't care if you have a lot of options as a vendor, but boy, the backends of those better be consistent.Meaning if I have a CI/CD tool in my portfolio and it only writes to two of them, shame on me. Then I should make sure that at least CI/CD, identity management, log management, monitoring, arguably your compute runtime should be a late-binding choice. And maybe that's blasphemous because somebody says, “I want to start up front knowing it's a function,” or, “I want to start it's a VM.” How about, as a developer, I couldn't care less. How about I just build cool software and maybe even at deploy time, I say, “This better fits in running in Kubernetes.” “This is better in a virtual machine.”And my cost of changing that later is meaningless because, hey, if it is in the container, I can switch it between three or four different runtimes, the identity management the same, it logs the exact same way, I can deploy CI/CD the same way. So, first off, if those things aren't the same, then the vendor is messing up. So, the customer shouldn't have to pay the cost of that. And then there gets to be other actual criteria. Look, I think you are looking at the workload itself, the team who makes it, and the strategy to figure out the runtime.It's easy for us. Google Compute Engine for VMs, containers go in GKE, managed services that need some containers, there are some apps around them, are Cloud Functions and Cloud Run. Like, it's fairly straightforward and it's going to be an OR situation—or an AND situation not an OR, which is great. But we're at least saying the premium way to run containers in Google Cloud for systems is GKE. There you go. If you do have a bunch of managed services in your architecture and you're stitching them together, then you want more serverless things like Cloud Run and Cloud Functions. And if you want to just really move some existing workload, GCE is your best choice. I like that that's fairly straightforward. There's still going to be some it depends, but it feels better than nine ways to run Kubernetes engines.Corey: I'm sure we'll see them in the fullness of time.Richard: [laugh].Corey: So, talk about Anthos a bit. That was a thing that was announced a while back and it was extraordinarily unclear what it was. And then I looked at the pricing and it was $10,000 a month with a one-year minimum commitment, and is like, “Oh, it's not for me. That's why I don't get it.” And I haven't really looked back at it since. But it is something else now. It almost feels like a wrapper brand, in some respects. How's it going? [unintelligible 00:29:26]?Richard: Yeah. Consumption, we'll talk more upcoming months on some of the adoption, but we're finally getting the hockey stick, which always comes delayed with platforms because nobody adopts platforms quickly. They buy the platform and a year later they start to actually build new development, migrate the things they have. So, we're starting to see the sort of growth. But back to your first point. And I even think I poorly tried to explain it a year ago with you. Basically, look, Anthos is the ability to manage fleets of GKE clusters, wherever they are. I don't care if they're on-prem, I don't care if they're in Google Cloud, I don't care if they're Amazon. We have one customer who only uses Anthos on AWS. Awesome, rock on.So, how do I put GKE clusters everywhere, but then do fleet management because look, some people are doing an app per cluster. They don't want to jam 50 apps in the cluster from different teams because they don't like the idea that this app requires root access; now you can screw around with mine. Or, you didn't update; that broke the cluster. I don't want any of that. So, you're going to see companies more, doing even app per cluster, app per developer per cluster.So, now I have a fleet problem. How do I keep it in sync? How do I make sure policy is consistent? Those sorts of things. So, Anthos is kind of solving the fleet management challenge and replacing people's first-gen app platform.Seeing a lot of those use cases, “Hey, we're retiring our first version of Docker Enterprise, Mesos, Cloud Foundry, even OpenShift,” saying, “All right, now's the time for our next version of our app platform. How about GKE, plus Cloud Run on top of it, plus other stuff?” Sounds good. So, going well is a, sort of—as you mentioned, there's a brand story here, mainly because we've also done two things that probably matter to you. A, we changed the price a lot.No minimum commit, remarkably at 20% of the cost it was when we launched, on purpose because we've gotten better at this. So, much cheaper, no minimum commit, pay as you go. Be on-premises, on bare metal with GKE. Pay by the hour, I don't care; sounds great. So, you can do that sort of stuff.But then more importantly, if you're a GKE customer and you just want config management, service mesh, things like that, now you can buy all of those independently as well. And Anthos is really the brand for fleet management of GKE. And if you're on Google Cloud only, it adds value. If you're off Google Cloud, if you're multi-cloud, I don't care. But I want to manage fleets of compute clusters and create them. We're going to keep doubling down on that.Corey: The big problem historically for understanding a lot of the adoption paradigm of Kubernetes has been that it was, to some extent, a reimagining of how Google ran and built software internally. And I thought at the time, the idea was—from a cynical perspective—that, “All right, well, your crappy apps don't run well on Google-style infrastructure so we're going to teach the entire world how to write software the way that we do.” And then you end up with people running their blog on top of Kubernetes, where it's one of those, like, the first blog post is, like, “How I spent the last 18 months building Kubernetes.” And, okay, that is certainly a philosophy and an approach, but it's almost approaching Windows 95 launch level of hype, where people who didn't own computers were buying copies of it, on some level. And I see the term come up in conversations in places where it absolutely has no place being brought up. “How do I run a Kubernetes cluster inside of my laptop?” And, “It's what you got going on in there, buddy?”Richard: [laugh].Corey: “What do you think you're trying to do here because you just said something that means something that I think is radically different to me than it is to you.” And again, I'm not here to judge other people's workflows; they're all terrible, except for mine, which is an opinion held by everyone about their own workflow. But understanding where people are, figuring out how to get there, how to meet customers where they are and empower them. And despite how heavily Google has been into the Kubernetes universe since its inception, you're very welcoming to companies—and loud-mouth individuals on Twitter—who have no use for Kubernetes. And working through various products you offer, I don't ever feel like a second-class citizen. There's really something impressive about that, of not letting the hype dictate the product and marketing decisions of it.Richard: Yeah, look, I think I tweeted it recently, I think the future of software is managed services with containers in the gap, for the most part. Whereas—if you can use managed services, please do. Use them wherever you can. And if you have to sling some code, maybe put it in a really portable thing that's really easy to run in lots of places. So, I think that's smart.But for us, look, I think we have the best container workflow from dev tools, and build tools, and artifact registries, and runtimes, but plenty of people are running containers, and you shouldn't be running Kubernetes all over the place. That makes sense for the workload, I think it's better than a VM at the retail edge. Can I run a small cluster, instead of a weird point-of-sale Windows app? Maybe. Maybe it makes sense to have a lightweight Kubernetes cluster there for consistency purposes.So, for me, I think it's a great medium for a subset of software. Google Cloud is going to take whatever you got, which is great. I think containers are great, but at the same time, I'm happily going to let you deploy a function that responds to you adding a storage item to a bucket, where at the same time give you a SaaS service that replaces the need for any code. All of those are terrific. So yeah, we love Kubernetes. We think it's great. We're going to be the best version to run it. But that's not going to be your whole universe.Corey: No, and I would argue it absolutely shouldn't be.Richard: [laugh]. Right. Agreed. Now again, for some companies, it's a great replacement for this giant fleet of VMs that all runs at eight percent utilization. Can I stick this into a bunch of high-density clusters? Absolutely you should. You're going to save an absolute fortune doing that and probably pick up some resilience and functionality benefits.But to your point, “Do I want to run a WordPress site in there?” I don't know, probably not. “Do I need to run my own MySQL?” I'd prefer you not do that. So, in a lot of cases, don't use it unless you have to. That should go for all compute nowadays. Use managed services.Corey: I'm a big believer in going down that approach just because it is so much easier than trying to build it yourself from popsicle sticks because you theoretically might have to move it someday in the future, even though you're not.Richard: [laugh]. Right.Corey: And it lets me feel better about a thing that isn't going to be used by anything that I'm doing in the near future. I just don't pretend to get it.Richard: No, I don't install a general purpose electric charger in my garage for any electric car I may get in the future; I charge for the one I have now. I just want it to work for my car; I don't want to plan for some mythical future. So yeah, premature optimization over architecture, or death in IT, especially nowadays where speed matters, don't waste your time building something that can run in nine clouds.Corey: Richard, I want to thank you for coming on again a year later to suffer my slings, arrows, and other various implements of misfortune. If people want to learn more about what you're doing, how you're doing it, possibly to pull a Forrest Brazeal and go work with you, where can they find you?Richard: Yeah, we're a fun place to work. So, you can find me on Twitter at @rseroter—R-S-E-R-O-T-E-R—hang out on LinkedIn, annoy me on my blog seroter.com as I try to at least explore our tech from time to time and mess around with it. But this is a fun place to work. There's a lot of good stuff going on here, and if you work somewhere else, too, we can still be friends.Corey: Thank you so much for your time today. Richard Seroter, director of outbound product management at Google. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment into which you have somehow managed to shove a running container.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

About Micheal Micheal Benedict leads Engineering Productivity at Pinterest. He and his team focus on developer experience, building tools and platforms for over a thousand engineers to effectively code, build, deploy and operate workloads on the cloud. Mr. Benedict has also built Infrastructure and Cloud Governance programs at Pinterest and previously, at Twitter -- focussed on managing cloud vendor relationships, infrastructure budget management, cloud migration, capacity forecasting and planning and cloud cost attribution (chargeback). Links: Pinterest: https://www.pinterest.com Teletraan: https://github.com/pinterest/teletraan Twitter: https://twitter.com/micheal Pinterestcareers.com: https://pinterestcareers.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: You know how git works right?Announcer: Sorta, kinda, not really. Please ask someone else!Corey: Thats all of us. Git is how we build things, and Netlify is one of the best way I've found to build those things quickly for the web. Netlify's git based workflows mean you don't have to play slap and tickle with integrating arcane non-sense and web hooks, which are themselves about as well understood as git. Give them a try and see what folks ranging from my fake Twitter for pets startup, to global fortune 2000 companies are raving about. If you end up talking to them, because you don't have to, they get why self service is important—but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y.comCorey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while, I like to talk to people who work at very large companies that are not in fact themselves a cloud provider. I know it sounds ridiculous. How can you possibly be a big company and not make money by selling managed NAT gateways to an unsuspecting public? But I'm told it can be done here to answer that question. And hopefully at least one other is Pinterest. It's head of engineering productivity, Micheal Benedict. Micheal, thank you for taking the time to join me today.Micheal: Hi, Corey, thank you for inviting me today. I'm really excited to talk to you.Corey: So, exciting times at Pinterest in a bunch of different ways. It was recently reported—which of course, went right to the top of my inbox as 500,000 people on Twitter all said, “Hey, this sounds like a ‘Corey would be interested in it' thing.” It was announced that you folks had signed a $3.2 billion commitment with AWS stretching until 2028. Now, if this is like any other large-scale AWS contract commitment deal that has been made public, you were probably immediately inundated with a whole bunch of people who are very good at arithmetic and not very good at business context saying, “$3.2 billion? You could build massive data centers for that. Why would anyone do this?” And it's tiresome, and that's the world in which we live. But I'm guessing you heard at least a little bit of that from the peanut gallery.Micheal: I did, and I always find it interesting when direct comparisons are made with the total amount that's been committed. And like you said, there's so many nuances that go into how to perceive that amount, and put it in context of, obviously, what Pinterest does. So, I at least want to take this opportunity to share with everyone that Pinterest has been on the cloud since day one. When Ben initially started the company, that product was launched—it was a simple Django app—it was launched on AWS from day one, and since then, it has grown to support 450-plus million MAUs over the course of the decade.And our infrastructure has grown pretty complex. We started with a bunch of EC2 machines and persisting data in S3, and since then we have explored an array of different products, in fact, sometimes working very closely with AWS, as well and helping them put together a product roadmap for some of the items they're working on as well. So, we have an amazing partnership with them, and part of the commitment and how we want to see these numbers is how does it unlock value for Pinterest as a business over time in terms of making us much more agile, without thinking about the nuances of the infrastructure itself. And that's, I think, one of the best ways to really put this into context, that it's not a single number we pay at the end [laugh] of the month, but rather, we are on track to spending a certain amount over a period of time, so this just keeps accruing or adding to that number. And we basically come out with an amazing partnership in AWS, where we have that commitment and we're able to leverage their products and full suite of items without any hiccups.Corey: The most interesting part of what you said is the word partner. And I think that's the piece that gets lost an awful lot when we talk about large-scale cloud negotiations. It's not like buying a car, where you can basically beat the crap out of the salesperson, you can act as if $400 price difference on a car is the difference between storm out of the dealership and sign the contract. Great, you don't really have to deal with that person ever again.In the context of a cloud provider, they run your production infrastructure, and if they have a bad day, I promise you're going to have a bad day, too. You want to handle those negotiations in a way that is respectful of that because they are your partner, whether you want them to be or not. Now, I'm not suggesting that any cloud provider is going to hold an awkward negotiation against the customer, but at the same time, there are going to be scenarios in which you're going to want to have strong relationships, where you're going to need to cash in political capital to some extent, and personally, I've never seen stupendous value in trying to beat the crap out of a company in order to get another tenth of a percent discount on a service you barely use, just because someone decided that well, we didn't do well in the last negotiation so we're going to get them back this time.That's great. What are you actually planning to do as a company? Where are you going? And the fact that you just alluded to, that you're not just a pile of S3 and EC2 instances speaks, in many ways, to that. By moving into the differentiated service world, suddenly you're able to do things that don't look quite as much like building a better database and start looking a lot more like servicing your users more effectively and well.Micheal: And I think, like you said, I feel like there's like a general skepticism in viewing that the cloud providers are usually out there to rip you apart. But in reality, that's not true. To your point, as part of the partnership, especially with AWS and Pinterest, we've got an amazing relationship going on, and behind the scenes, there's a dedicated team at Pinterest, called the Infrastructure Governance Team, a cross-functional team with folks from finance, legal, engineering, product, all sitting together and working with our AWS partners—even the AWS account managers at the times are part of that—to help us make both Pinterest successful, and in turn, AWS gets that amazing customer to work with in helping build some of their newer products as well. And that's one of the most important things we have learned over time is that there's two parts to it; when you want to help improve your business agility, you want to focus not just on the bottom line numbers as they are. It's okay to pay a premium because it offsets the people capital you would have to invest in getting there.And that's a very tricky way to look at math, but that's what these teams do; they sit down and work through those specifics. And for what it's worth, in our conversations, the AWS teams always come back with giving us very insightful data on how we're using their systems to help us better think about how we should be pricing or looking things ahead. And I'm not the expert on this; like I said, there's a dedicated team sitting behind this and looking through and working through these deals, but that's one of the important takeaways I hope the users—or the listeners of this podcast then take away that you want to treat your cloud provider as your partner as much as possible. They're not always there to screw you. That's not their goal. And I apologize for using that term. It is important that you set that expectations that it's in their best interest to actually make you successful because that's how they make money as well.Corey: It's a long-term play. I mean, they could gouge you this quarter, and then you're trying to evacuate as fast as possible. Well, they had a great quarter, but what's their long-term prospect? There are two competing philosophies in the world of business; you can either make a lot of money quickly, or you can make a little bit of money and build it over time in a sustained way. And it's clear the cloud providers are playing the long game on this because they basically have to.Micheal: I mean, it's inevitable at this point. I mean, look at Pinterest. It is one of those success stories. Starting as a Django app on a bunch of EC2 machines to wherever we are right now with having a three-plus billion dollar commitment over a span of couple of years, and we do spend a pretty significant chunk of that on a yearly basis. So, in this case, I'm sure it was a great successful partnership.And I'm hoping some of the newer companies who are building the cloud from the get-go are thinking about it from that perspective. And one of the things I do want to call out, Corey, is that we did initially start with using the primitive services in AWS, but it became clear over time—and I'm sure you heard of the term multi-cloud and many of that—you know, when companies start evaluating how to make the most out of the deals they're negotiating or signing, it is important to acknowledge that the cost of any of those evaluations or even thinking about migrations never tends to get factored in. And we always tend to treat that as being extremely simple or not, but those are engineering resources you want to be spending more building on the product rather than these crazy costly migrations. So, it's in your best interest probably to start using the most from your cloud provider, and also look for opportunities to use other cloud providers—if they provide more value in certain product offerings—rather than thinking about a complete lift-and-shift, and I'm going to make DR as being the primary case on why I want to be moving to multi-cloud.Corey: Yeah. There's a question, too, of the numbers on paper look radically different than the reality of this. You mentioned, Pinterest has been on AWS since the beginning, which means that even if an edict had been passed at the beginning, that, “Thou shalt never build on anything except EC2 and S3. The end. Full stop.”And let's say you went down that rabbit hole of, “Oh, we don't trust their load balancers. We're going to build our own at home. We have load balancers at home. We'll use those.” It's terrible, but even had you done that and restricted yourselves just to those baseline building blocks, and then decide to do a cloud migration, you're still looking back at over a decade of experience where the app has been built unconsciously reflecting the various failure modes that AWS has, the way that it responds to API calls, the latency in how long it takes to request something versus it being available, et cetera, et cetera.So, even moving that baseline thing to another cloud provider is not a trivial undertaking by any stretch of the imagination. But that said—because the topic does always come up, and I don't shy away from it; I think it's something people should go into with an open mind—how has the multi-cloud conversation progressed at Pinterest? Because there's always a multi-cloud conversation.Micheal: We have always approached it with some form of… openness. It's not like we don't want to be open to the ideas, but you really want to be thinking hard on the business case and the business value something provides on why you want to be doing x. In this case, when we think about multi-cloud—and again, Pinterest did start with EC2 and S3, and we did keep it that way for a long time. We built a lot of primitives around it, used it—for example, my team actually runs our bread and butter deployment system on EC2. We help facilitate deployments across a 100,000-plus machines today.And like you said, we have built that system keeping in mind how AWS works, and understanding the nuances of region and AZ failovers and all of that, and help facilitate deployments across 1000-plus microservices in the company. So, thinking about leveraging, say, a Google Cloud instance and how that works, in theory, we can always make a case for engineering to build our deployment system and expand there, but there's really no value. And one of the biggest cases, usually, when multi-cloud comes in is usually either negotiation for price or actually a DR strategy. Like, what if AWS goes down in and us-east-1? Well, let's be honest, they're powering half the internet [laugh] from that one single—Corey: Right.Micheal: Yeah. So, if you think your business is okay running when AWS goes down and half the internet is not going to be working, how do you want to be thinking about that? So, DR is probably not the best reason for you to be even exploring multi-cloud. Rather, you should be thinking about what the cloud providers are offering as a very nuanced offering which your current cloud provider is not offering, and really think about just using those specific items.Corey: So, I agree that multi-cloud for DR purposes is generally not necessarily the best approach with the idea of being able to failover seamlessly, but I like the idea for backups. I mean, Pinterest is a publicly-traded company, which means that among other things, you have to file risk disclosures and be responsive to auditors in a variety of different ways. There are some regulations to start applying to you. And the idea of, well, AWS builds things out in a super effective way, region separation, et cetera, whenever I talk to Amazonians, they are always surprised that anyone wouldn't accept that, “Oh, if you want backups use a different region. Problem solved.”Right, but it is often easier for me to have a rehydrate the business level of backup that would take weeks to redeploy living on another cloud provider than it is for me to explain to all of those auditors and regulators and financial analysts, et cetera why I didn't go ahead and do that path. So, there's always some story for okay, what if AWS decides that they hate us and want to kick us off the platform? Well, that's why legal is involved in those high-level discussions around things like risk, and indemnity, and termination for convenience and for cause clauses, et cetera, et cetera. The idea of making an all-in commitment to a cloud provider goes well beyond things that engineering thinks about. And it's easy for those of us with engineering backgrounds to be incredibly dismissive of that of, “Oh, indemnity? Like, when does AWS ever lose data?” “Yeah, but let's say one day they do. What is your story going to be when asked some very uncomfortable questions by people who wanted you to pay attention to this during the negotiation process?” It's about dotting the i's and crossing the t's, especially with that many commas in the contractual commitments.Micheal: No, it is true. And we did evaluate that as an option, but one of the interesting things about compliance, and especially auditing as well, we generally work with the best in class consultants to help us work through the controls and how we audit, how we look at these controls, how to make sure there's enough accountability going through. The interesting part was in this case, as well, we were able to work with AWS in crafting a lot of those controls and setting up the right expectations as and when we were putting proposals together as well. Now, again, I'm not an expert on this and I know we have a dedicated team from our technical program management organization focused on this, but early on we realized that, to your point, the cost of any form of backups and then being able to audit what's going in, look at all those pipelines, how quickly we can get the data in and out it was proving pretty costly for us. So, we were able to work out some of that within the constructs of what we have with our cloud provider today, and still meet our compliance goals.Corey: That's, on some level, the higher point, too, where everything is everything comes down to context; everything comes down to what the business demands, what the business requires, what the business will accept. And I'm not suggesting that in any case, they're wrong. I'm known for beating the ‘Multi-cloud is a bad default decision' drum, and then people get surprised when they'll have one-on-one conversations, and they say, “Well, we're multi-cloud. Do you think we're foolish?” “No. You're probably doing the right thing, just because you have context that is specific to your business that I, speaking in a general sense, certainly don't have.”People don't generally wake up in the morning and decide they're going to do a terrible job or no job at all at work today, unless they're Facebook's VP of Integrity. So, it's not the sort of thing that lends itself to casual tweet size, pithy analysis very often. There's a strong dive into what is the level of risk a business can accept? And my general belief is that most companies are doing this stuff right. The universal constant in all of my consulting clients that I have spoken to about the in-depth management piece of things is, they've always asked the same question of, “So, this is what we've done, but can you introduce us to the people who are doing it really right, who have absolutely nailed this and gotten it all down?” “It's, yeah, absolutely no one believes that that is them, even the folks who are, from my perspective, pretty close to having achieved it.”But I want to talk a bit more about what you do beyond just the headline-grabbing large dollar figure commitment to a cloud provider story. What does engineering productivity mean at Pinterest? Where do you start? Where do you stop?Micheal: I want to just quickly touch upon that last point about multi-cloud, and like you said, every company works within the context of what they are given and the constraints of their business. It's probably a good time to give a plug to my previous employer, Twitter, who are doing multi-cloud in a reasonably effective way. They are on the data centers, they do have presence on Google Cloud, and AWS, and I know probably things have changed since a couple of years now, but they have embraced that environment pretty effectively to cater to their acquisitions who were on the public cloud, help obviously, with their initial set of investments in the data center, and still continue to scale that out, and explore, in this case, Google Cloud for a variety of other use cases, which sounds like it's been extremely beneficial as well.So, to your point, there is probably no right way to do this. There's always that context, and what you're working with comes into play as part of making these decisions. And it's important to take a lot of these with a grain of salt because you can never understand the decisions, why they were made the way they were made. And for what it's worth, it sort of works out in the end. [laugh]. I've rarely heard a story where it's never worked out, and people are just upset with the deals they've signed. So, hopefully, that helps close that whole conversation about multi-cloud.Corey: I hope so. It's one of those areas where everyone has an opinion and a lot of them do not necessarily apply universally, but it's always fun to take—in that case, great, I'll take the lesser trod path of everyone's saying multi-cloud is great, invariably because they're trying to sell you something. Yeah, I have nothing particularly to sell, folks. My argument has always been, in the absence of a compelling reason not to, pick a provider and go all in. I don't care which provider you pick—which people are sometimes surprised to hear.It's like, “Well, what if they pick a cloud provider that you don't do consulting work for?” Yeah, it turns out, I don't actually need to win every AWS customer over to have a successful working business. Do what makes sense for you, folks. From my perspective, I want this industry to be better. I don't want to sit here and just drum up business for myself and make self-serving comments to empower that. Which apparently is a rare tactic.Micheal: No, that's totally true, Corey. One of the things you do is help people with their bills, so this has come up so many times, and I realize we're sort of going off track a bit from that engineering productivity discussion—Corey: Oh, which is fine. That's this entire show's theme, if it has one.Micheal: [laugh]. So, I want to briefly just talk about the whole billing and how cost management works because I know you spend a lot of time on that and you help a lot of these companies be effective in how they manage their bills. These questions have come up multiple times, even at Pinterest. We actually in the past, when I was leading the infrastructure governance organization, we were working with other companies of our similar size to better understand how they are looking into getting visibility into their cost, setting sort of the right controls and expectations within the engineering organization to plan, and capacity plan, and effectively meet those plans in a certain criteria, and then obviously, if there is any risk to that, actively manage risk. That was like the biggest thing those teams used to do.And we used to talk a lot trade notes, and get a better sense of how a lot of these companies are trying to do—for example, Netflix, or Lyft, or Stripe. I recall Netflix, content was their biggest spender, so cloud spending was like way down in the list of things for them. [laugh]. But regardless, they had an active team looking at this on a day-to-day basis. So, one of the things we learned early on at Pinterest is that start investing in those visibility tools early on.No one can parse the cloud bills. Let's be honest. You're probably the only person who can reverse… [laugh] engineer an architecture diagram from a cloud bill, and I think that's like—definitely you should take a patent for that or something. But in reality, no one has the time to do that. You want to make sure your business leaders, from your finance teams to engineering teams to head of the executives all have a better understanding of how to parse it.So, investing engineering resources, take that data, how do you munch it down to the cost, the utilization across the different vectors of offerings, and have a very insightful discussion. Like, what are certain action items we want to be taking? It's very easy to see, “Oh, we overspent EC2,” and we want to go from there. But in reality, that's not just that thing; you will start finding out that EC2 is being used by your Hadoop infrastructure, which runs hundreds of thousands of jobs. Okay, now who's actually responsible for that cost? You might find that one job which is accruing, sort of, a lot of instance hours over a period of time and a shared multi-tenant environment, how do you attribute that cost to that particular cost center?Corey: And then someone left the company a while back, and that job just kept running in perpetuity. No one's checked the output for four years, I guess it can't be that necessarily important. And digging into it requires context. It turns out, there's no SaaS tool to do this, which is unfortunate for those of us who set out originally to build such a thing. But we discovered pretty early on the context on this stuff is incredibly important.I love the thing you're talking about here, where you're discussing with your peer companies about these things because the advice that I would give to companies with the level of spend that you folks do is worlds apart from what I would advise someone who's building something new and spending maybe 500 bucks a month on their cloud bill. Those folks do not need to hire a dedicated team of people to solve for these problems. At your scale, yeah, you probably should have had some people in [laugh] here looking at this for a while now. And at some point, the guidance changes based upon scale. And if there's one thing that we discover from the horrible pages of Hacker News, it's that people love applying bits of wisdom that they hear in wildly inappropriate situations.How do you think about these things at that scale? Because, a simple example: right now I spend about 1000 bucks a month at The Duckbill Group, on our AWS bill. I know. We have one, too. Imagine that. And if I wind up just committing admin credentials to GitHub, for example, and someone compromises that and start spinning things up to mine all the Bitcoin, yeah, I'm going to notice that by the impact it has on the bill, which will be noticeable from orbit.At the level of spend that you folks are at, at company would be hard-pressed to spin up enough Bitcoin miners to materially move the billing needle on a month-to-month basis, just because of the sheer scope and scale. At small bill volumes, yeah, it's pretty easy to discover the thing that spiking your bill to three times normal. It's usually a managed NAT gateway. At your scale, tripling the bill begins to look suspiciously like the GDP of a small country, so what actually happened here? Invariably, at that scale, with that level of massive multiplier, it's usually the simplest solution, an error somewhere in the AWS billing system. Yes, they exist. Imagine that.Micheal: They do exist, and we've encountered that.Corey: Kind of heartstopping, isn't it?Micheal: [laugh]. I don't know if you remember when we had the big Spectre and the Meltdown, right, and those were interesting scenarios for us because we had identified a lot of those issues early on, given the scale we operate, and we were able to, sort of, obviously it did have an impact on the builds and everything, but that's it; that's why you have these dedicated teams to fix that. But I think one of the points you made, these are large bills and you're never going to have a 3x jump the next day. We're not going to be seeing that. And if that happens, you know, God save us. [laugh].But to your point, one of the things we do still want to be doing is look at trends, literally on a week-over-week basis because even a one percentage move is a pretty significant amount, if you think about it, which could be funding some other aspects of the business, which we would prefer to be investing on. So, we do want to have enough rigor and controls in place in our technical stack to identify and alert when something is off track. And it becomes challenging when you start using those higher-order services from your public cloud provider because there's no clear insights on how do you, kind of, parse that information. One of the biggest challenges we had at Pinterest was tying ownership to all these things.No, using tags is not going to cut it. It was so difficult for us to get to a point where we could put some sense of ownership in all the things and the resources people are using, and then subsequently have the right conversation with our ads infrastructure teams, or our product teams to help drive the cost improvements we want to be seeing. And I wouldn't be surprised if that's not a challenge already, even for the smaller companies who have bills in the tunes of tens and thousands, right?Corey: It is. It's predicting the spend and trying to categorize it appropriately; that's the root of all AWS bill panic on the corporate level. It's not that the bill is 20% higher, so we're going to go broke. Most companies spend far more on payroll than they do on infrastructure—as you mentioned with Netflix, content is a significantly larger [laugh] expense than any of those things; real estate, it's usually right up there too—but instead it's, when you're trying to do business forecasting of, okay, if we're going to have an additional 1000 monthly active users, what will the cost for us be to service those users and, okay, if we're seeing a sudden 20% variance, if that's the new normal, then well, that does change our cost projections for a number of years, what happens? When you're public, there starts to become the question of okay, do we have to restate earnings or what's the deal here?And of course, all this sidesteps past the unfortunate reality that, for many companies, the AWS bill is not a function of how many customers you have; it's how many engineers you hired. And that is always the way it winds up playing out for some reason. “It's why did we see a 10% increase in the bill? Yeah, we hired another data science team. Oops.” It's always seems to be the data science folks; I know I'd beat up on those folks a fair bit, and my apologies. And one day, if they analyze enough of the data, they might figure out why.Micheal: So, this is where I want to give a shout out to our data science team, especially some of the engineers working in the Infrastructure Governance Team putting these charts together, helping us derive insights. So, definitely props to them.I think there's a great segue into the point you made. As you add more engineers, what is the impact on the bottom line? And this is one of the things actually as part of engineering productivity, we think about as well on a long-term basis. Pinterest does have over 1000-plus engineers today, and to large degree, many of them actually have their own EC2 instances today. And I wouldn't say it's a significant amount of cost, but it is a large enough number, were shutting down a c5.9xl can actually fund a bunch of conference tickets or something else.And then you can imagine that sort of the scale you start working with at one point. The nuance here is though, you want to make sure there's enough flexibility for these engineers to do their local development in a sustainable way, but when moving to, say production, we really want to tighten the flexibility a bit so they don't end up doing what you just said, spin up a bunch of machines talking to the API directly which no one will be aware of.I want to share a small anecdote because when back in the day, this was probably four years ago, when we were doing some analysis on our bills, we realized that there was a huge jump every—I believe Wednesday—in our EC2 instances by almost a factor of, like, 500 to 600 instances. And we're like, “Why is this happening? What is going on?” And we found out there was an obscure job written by someone who had left the company, calling an EC2 API to spin up a search cluster of 500 machines on-demand, as part of pulling that ETL data together, and then shutting that cluster down. Which at times didn't work as expected because, you know, obviously, your Hadoop jobs are very predictable, right?So, those are the things we were dealing with back in the day, and you want to make sure—since then—this is where engineering productivity as team starts coming in that our job is to enable every engineer to be doing their best work across code building and deploying the services. And we have done this.Corey: Right. You and I can sit here and have an in-depth conversation about the intricacies of AWS billing in a bunch of different ways because in different ways we both specialize in it, in many respects. But let's say that Pinterest theoretically was foolish enough to hire me before I got into this space as an engineer, for terrifying reasons. And great. I start day one as a typical software developer if such a thing could be said to exist. How do you effectively build guardrails in so that I don't inadvertently wind up spinning up all the EC2 instances available to me within an account, which it turns out are more than one might expect sometimes, but still leave me free to do my job without effectively spending a nine-month safari figuring out how AWS bills work?Micheal: And this is why teams like ours exist, to help provide those tools to help you get started. So today, we actually don't let anyone directly use AWS APIs, or even use the UI for that matter. And I think you'll soon realize, the moment you hit, like, probably 30 or 40 people in your organization, you definitely want to lock it down. You don't want that access to be given to anyone or everyone. And then subsequently start building some higher-order tools or abstraction so people can start using that to control effectively.In this case, if you're a new engineer, Corey, which it seems like you were, at some point—Corey: I still write code like I am, don't worry.Micheal: [laugh]. So yes, you would get access to our internal tool to actually help spin up what we call is a dev app, where you get a chance to, obviously, choose the instance size, not the instance type itself, and we have actually constrained the instance types we have approved within Pinterest as well. We don't give you the entire list you get a chance to choose and deploy to. We actually have constraint to based on the workload types, what are the instance types we want to support because in the future, if we ever want to move from c3 to c5—and I've been there, trust me—it is not an easy thing to do, so you want to make sure that you're not letting people just use random instances, and constrain that by building some of these tools. As a new engineer, you would go in, you'd use the tool, and actually have a dev app provisioned for you with our Pinterest image to get you started.And then subsequently, we'll obviously shut it down if we see you not being using it over a certain amount of time, but those are sort of the guardrails we've put in over there so you never get a chance to directly ever use the EC2 APIs, or any of those AWS APIs to do certain things. The similar thing applies for S3 or any of the higher-order tools which AWS will provide, too.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: How does that interplay with AWS launches yet another way to run containers, for example, and that becomes a valuable potential avenue to get some business value for a developer, but the platform you built doesn't necessarily embrace that capability? Or they release a feature to an existing tool that you use that could potentially be a just feature capability story, much more so than a cost savings one. How do you keep track of all of that and empower people to use those things so they're not effectively trying to reimplement DynamoDB on top of EC2?Micheal: That's been a challenge, actually, in the past for us because we've always been very flexible where engineers have had an opportunity to write their own solutions many a times rather than leveraging the AWS services, and of late, that's one of the reasons why we have an infrastructure organization—an extremely lean organization for what it's worth—but then still able to achieve outsized outputs. Where we evaluate a lot of these use cases, as they come in and open up different aspects of what we want to provide say directly from AWS, or build certain abstractions on top of it. Every time we talk about containers, obviously, we always associate that with something like Kubernetes and offerings from there on; we realized that our engineers directly never ask for those capabilities. They don't come in and say, “I need a new container orchestration system. Give that to me, and I'm going to be extremely productive.”What people actually realize is that if you can provide them effective tools and that can help them get their job done, they would be happy with it. For example, like I said, our deployment system, which is actually an open-source system called Teletraan. That is the bread and butter at Pinterest at which my team runs. We operate 100,000-plus machines. We have actually looked into container orchestration where we do have a dedicated Kubernetes team looking at it and helping certain use cases moved there, but we realized that the cost of entire migrations need to be evaluated against certain use cases which can benefit from being on Kubernetes from day one. You don't want to force anyone to move there, but give them the right incentives to move there. Case in point, let's upgrade your OS. Because if you're managing machines, obviously everyone loves to upgrade their OSes.Corey: Well, it's one of the things I love savings plans versus RIs; you talk about the c3 to c5 migration and everyone has a story about one of those, but the most foolish or frustrating reason that I ever saw not to do the upgrade was what we bought a bunch of Reserved Instances on the C3s and those have a year-and-a-half left to run. And it's foolish not on the part of customers—it's economically sound—but on the part of AWS where great, you're now forcing me to take a contractual commitment to something that serves me less effectively, rather than getting out of the way and letting me do my job. That's why it's so important to me at least, that savings plans cover Fargate and Lambda, I wish they covered SageMaker instead of SageMaker having its own thing because once again, you're now architecturally constrained based upon some ridiculous economic model that they have imposed on us. But that's a separate rant for another time.Micheal: No, we actually went through that process because we do have a healthy balance of how we do Reserved Instances and how we look at on-demand. We've never been big users have spot in the past because just the spot market itself, we realized that putting that pressure on our customers to figure out how to manage that is way more. When I say customers, in this case, engineers within the organization.Corey: Oh, yes. “I want to post some pictures on Pinterest, so now I have to understand the spot market. What?” Yeah.Micheal: [laugh]. So, in this case, when we even we're moving from C3 to C5—and this is where the partnership really plays out effectively, right, because it's also in the best interest of AWS to deprecate their aging hardware to support some of these new ones where they could also be making good enough premium margins for what it's worth and give the benefit back to the user. So, in this case, we were able to work out an extremely flexible way of moving to a C5 as soon as possible, get help from them, actually, in helping us do that, too, allocating capacity and working with them on capacity management. I believe at one point, we were actually one of the largest companies with a C3 footprint and it took quite a while for us to move to C5. But rest assured, once we moved, the savings was just immense. We were able to offset any of those RI and we were able to work behind the scenes to get that out. But obviously, not a lot of that is considered in a small-scale company just because of, like you said, those constraints which have been placed in a contractual obligation.Corey: Well, this is an area in which I will give the same guidance to companies of your scale as well as small-scale companies. And by small-scale, I mean, people on the free tier account, give or take, so I do mean the smallest of the small. Whenever you wind up in a scenario where you find yourself architecturally constrained by an economic barrier like this, reach out to your account manager. I promise you have one. Every account, even the tiny free tier accounts, have an account manager.I have an account manager, who I have to say has probably one of the most surreal jobs that AWS, just based upon the conversations I throw past him. But it's reaching out to your provider rather than trying to solve a lot of this stuff yourself by constraining how you're building things internally is always the right first move because the worst case is you don't get anywhere in those conversations. Okay, but at least you explored that, as opposed to what often happens is, “Oh, yeah. I have a switch over here I can flip and solve your entire problem. Does that help anything?”Micheal: Yeah.Corey: You feel foolish finding that out only after nine months of dedicated work, it turns out.Micheal: Which makes me wonder, Corey. I mean, do you see a lot of that happening where folks don't tend to reach out to their account managers, or rather treat them as partners in this case, right? Because it sounds like there is this unhealthy tension, I would say, as to what is the best help you could be getting from your account managers in this case.Corey: Constantly. And the challenge comes from a few things, in my experience. The first is that the quality of account managers and the technical account managers—the folks who are embedded many cases with your engineering teams in different ways—does vary. AWS is scaling wildly and bursting at the seams, and people are hard to scale.So, some are fantastic, some are decidedly less so, and most folks fall somewhere in the middle of that bell curve. And it doesn't take too many poor experiences for the default to be, “Oh, those people are useless. They never do anything we want, so why bother asking them?” And that leads to an unhealthy dynamic where a lot of companies will wind up treating their AWS account manager types as a ticket triage system, or the last resort of places that they'll turn when they should be involved in earlier conversations.I mean, take Pinterest as an example of this. I'm not sure how many technical account managers you have assigned to your account, but I'm going to go out on a limb and guess that the ratio of technical account managers to engineers working on the environment is incredibly lopsided. It's got to be a high ratio just because of the nature of how these things work. So, there are a lot of people who are actively working on things that would almost certainly benefit from a more holistic conversation with your AWS account team, but it doesn't occur to them to do it just because of either perceived biases around levels of competence, or poor experiences in the past, or simply not knowing the capabilities that are there. If I could tell one story around the AWS account management story, it would be talk to folks sooner about these things.And to be clear, Pinterest has this less than other folks, but AWS does themselves no favors by having a product strategy of, “Yes,” because very often in service of those conversations with a number of companies, there is the very real concern of are they doing research so that they can launch a service that competes with us? Amazon as a whole launching a social network is admittedly one of the most hilarious ideas I [laugh] can come up with and I hope they take a whack at it just to watch them learn all these lessons themselves, but that is again, neither here nor there.Micheal: That story is very interesting, and I think you mentioned one thing; it's just that lack of trust, or even knowing what the account managers can actually do for you. There seems to be just a lack of education on that. And we also found it the hard way, right? I wouldn't say that Pinterest figured this out on day one. We evolved sort of a relationship over time. Yes, our time… engagements are, sort of, lopsided, but we were able to negotiate that as part of deals as we learned a bit more on what we can and we cannot do, and how these individuals are beneficial for Pinterest as well. And—Corey: Well, here's a question for you, without naming names—and this might illustrate part of the challenge customers have—how long has your account manager—not the technical account managers, but your account manager—been assigned to your account?Micheal: I've been at Pinterest for five years and I've been working with the same person. And he's amazing.Corey: Which is incredibly atypical. At a lot of smaller companies, it feels like, “Oh, I'm your account manager being introduced to you.” And, “Are you the third one this year? Great.” What happens is that if the account manager excels, very often they get promoted and work with a smaller number of accounts at larger spend, and whereas if they don't find that AWS is a great place for them for a variety of reasons, they go somewhere else and need to be backfilled.So, at the smaller account, it's, “Great. I've had more account managers in a year than you've had in five.” And that is often the experience when you start seeing significant levels of rotation, especially on the customer engineering side where you wind up with you have this big kickoff, and everyone's aware of all the capabilities and you look at it three years later, and not a single person who was in that kickoff is still involved with the account on either side, and it's just sort of been evolving evolutionarily from there. One thing that we've done in some of our larger accounts as part of our negotiation process is when we see that the bridges have been so thoroughly burned, we will effectively request a full account team cycle, just because it's time to get new faces in where the customer, in many cases unreasonably, is not going to say, “Yeah but a year-and-a-half ago you did this terrible thing and we're still salty about it.” Fine, whatever. I get it. People relationships are hard. Let's go ahead and swap some folks out so that there are new faces with new perspectives because that helps.Micheal: Well, first off, if you had so many switches in account manager, I think that's something speaks about [laugh] how you've been working, too. I'm just kidding. There are a bu—Corey: Entirely possible. In seriousness, yes. But if you talk to—like, this is not just me because in my case, yeah, I feel like my account manager is whoever drew the short straw that week because frankly, yeah, that does seem like a great punishment to wind up passing out to someone who is underperforming. But for a lot of folks who are in the mid-tier, like, spending $50 to $100,000 a month, this is a very common story.Micheal: Yeah. Actually, we've heard a bit about this, too. And like you said, I think maintaining context is the most thing. You really want your account manager to vouch for you, really be your champion in those meetings because AWS, like you said is so large, getting those exec time, and reviews, and there's so many things that happen, your account manager is the champion for you, or right there. And it's important and in fact in your best interest to have a great relationship with them as well, not treat them as, oh yet another vendor.And I think that's where things start to get a bit messy because when you start treating them as yet another vendor, there is no incentive for them to do the best for you, too. You know, people relationships are hard. But that said though, I think given the amount of customers like these cloud companies are accruing, I wouldn't be surprised; every account manager seems to be extremely burdened. Even in our case, although I've been having a chance to work with this one person for a long time, we've actually expanded. We have now multiple account managers helping us out as we've started scaling to use certain aspects of AWS which we've never explored before.We were a bit constrained and reserved about what service we want to use because there have been instances where we have tried using something and we have hit the wall pretty immediately. API rate limits, or it's not ready for primetime, and we're like, “Oh, my God. Now, what do we do?” So, we have a bit more cautious. But that said, over time, having an account manager who understands how you work, what scale you have, they're able to advocate with the internal engineering teams within the cloud provider to make the best of supporting you as a customer and tell that success story all the way out.So yeah, I can totally understand how this may be hard, especially for those small companies. For what it's worth, I think the best way to really think about it is not treat them as your vendor, but really go out on a limb there. Even though you signed a deal with them, you want to make sure that you have the continuing relationship with them to have—represent your voice better within the company. Which is probably hard. [laugh].Corey: That's always the hard part. Honestly, if this were the sort of thing that were easy to automate, or you could wind up building out something that winds up helping companies figure out how to solve these things programmatically, talk about interesting business problems that are only going to get larger in the fullness of time. This is not going away, even if AWS stopped signing up new customers entirely right now, they would still have years of growth ahead of them just from organic growth. And take a company with the scale of Pinterest and just think of how many years it would take to do a full-on exodus, even if it became priority number one. It's not realistic in many cases, which is why I've never been a big fan of multi-cloud as an approach for negotiation. Yeah, AWS has more data on those points than any of us do; they're not worried about it. It just makes you sound like an unsophisticated negotiator. Pick your poison and lean in.Micheal: That is the truth you just mentioned, and I probably want to give a call out to our head of infrastructure, [Coburn 00:42:13]. He's also my boss, and he had brought this perspective as well. As part of any negotiation discussions, like you just said, AWS has way more data points on this than what we think we can do in terms of talking about, “Oh, we are exploring this other cloud provider.” And it's—they would be like, “Yeah. Do tell me more [laugh] how that's going.”And it's probably in the best interest to never use that as a negotiation tactic because they clearly know the investments that's going to build on what you've done, so you might as well be talking more—again, this is where that relationship really plays together because you want both of them to be successful. And it's in their best interest to still keep you happy because the good thing about at least companies of our size is that we're probably, like, one phone call away from some of their executive team, where we could always talk about what didn't work for us. And I know not everyone has that opportunity, but I'm really hoping and I know at least with some of the interactions we've had with the AWS teams, they're actively working and building that relationship more and more, giving access to those customer advisory boards, and all of them to have those direct calls with the executives. I don't know whether you've seen that in your experience in helping some of these companies?Corey: Have a different approach to it. It turns out when you're super loud and public and noisy about AWS and spend too much time in Seattle, you start to spend time with those people on a social basis. Because, again, I'm obnoxious and annoying to a lot of AWS folks, but I'm also having an obnoxious habit of being right in most of the things I'm pointing out. And that becomes harder and harder to ignore. I mean, part of the value that I found in being able to do this as a consultant is that I begin to compare and contrast different customer environments on a consistent ongoing basis.I mean, the reason that negotiation works well from my perspective is that AWS does a bunch of these every week, and customers do these every few years with AWS. And well, we do an awful lot of them, too, and it's okay, we've seen different ways things can get structured and it doesn't take too long and too many engagements before you start to see the points of commonality in how these things flow together. So, when we wind up seeing things that a customer is planning on architecturally and looking to do in the future, and, “Well, wait a minute. Have you talked to the folks negotiating the contract about this? Because that does potentially have bearing and it provides better data than what AWS is gathering just through looking at overall spend trends. So yeah, bring that up. That is absolutely going to impact the type of offer you get.”It just comes down to understanding the motivators that drive folks and it comes down to, I think understanding the incentives. I will say that across the board, I have never yet seen a deal from AWS come through where it was, “Okay, at this point you're just trying to hoodwink the customer and get them to sign on something that doesn't help them.” I've seen mistakes that can definitely lead to that impression, and I've seen areas where they're doing data is incomplete and they're making assumptions that are not borne out in reality. But it's not one of those bad faith type—Micheal: Yeah.Corey: —of negotiations. If it were, I would be framing a lot of this very differently. It sounds weird to say, “Yeah, your vendor is not trying to screw you over in this sense,” because look at the entire IT industry. How often has that been true about almost any other vendor in the fullness of time? This is something a bit different, and I still think we're trying to grapple with the repercussions of that, from a negotiation standpoint and from a long-term business continuity standpoint, when your faith is linked—in a shared fate context—with your vendor.Micheal: It's in their best interest as well because they're trying to build a diversified portfolio. Like, if they help 100 companies, even if one of them becomes the next Pinterest, that's great, right? And that continued relationship is what they're aiming for. So, assuming any bad faith over there probably is not going to be the best outcome, like you said. And two, it's not a zero-sum game.I always get a sense that when you're doing these negotiations, it's an all-or-nothing deal. It's not. You have to think they're also running a business and it's important that you as your business, how okay are you with some of those premiums? You cannot get a discount on everything, you cannot get the deal or the numbers you probably want almost everything. And to your point, architecturally, if you're moving in a certain direction where you think in the next three years, this is what your usage is going to be or it will come down to that, obviously, you should be investing more and negotiating that out front rather than managed NAT [laugh] gateways, I guess. So, I think that's also an important mindset to take in as part of any of these negotiations. Which I'm assuming—I don't know how you folks have been working in the past, but at least that's one of the key items we have taken in as part of any of these discussions.Corey: I would agree wholeheartedly. I think that it just comes down to understanding where you're going, what's important, and again in some cases knowing around what things AWS will never bend contractually. I've seen companies spend six weeks or more trying to get to negotiate custom SLAs around services. Let me save everyone a bunch of time and money; they will not grant them to you.Micheal: Yeah.Corey: I promise. So, stop asking for them; you're not going to get them. There are other things they will negotiate on that they're going to be highly case-dependent. I'm hesitant to mention any of them just because, “Well, wait a minute, we did that once. Why are you talking about that in public?” I don't want to hear it and confidentiality matters. But yeah, not everything is negotiable, but most things are, so figuring out what levers and knobs and dials you have is important.Micheal: We also found it that way. AWS does cater to their—they are a platform and they are pretty clear in how much engagement—even if we are one of their top customers, there's been many times where I know their product managers have heavily pushed back on some of the requests we have put in. And that makes me wonder, they probably have the same engagement even with the smallest of customers, there's always an implicit assumption that the big fish is trying to get the most out of your public cloud providers. To your point, I don't think that's true. We're rarely able to negotiate anything exclusive in terms of their product offerings just for us, if that makes sense.Case in point, tell us your capacity [laugh] for x instances or type of instances, so we as a company would know how to plan out our scale-ups or scale-downs. That's not going to happen exclusively for you. But those kind of things are just, like, examples we have had a chance to work with their product managers and see if, can we get some flexibility on that? For what it's worth, though, they are willing to find a middle ground with you to make sure that you get your answers and, obviously, you're being successful in your plans to use certain technologies they offer or [unintelligible 00:48:31] how you use their services.Corey: So, I know we've gone significantly over time and we are definitely going to do another episode talking about a lot of the other things that you're involved in because I'm going to assume that your full-time job is not worrying about the AWS bill. In fact, you do a fair number of things beyond that; I just get stuck on that one, given that it is but I eat, sleep, breathe, and dream about.Micheal: Absolutely. I would love to talk more, especially about how we're enabling our engineers to be extremely productive in this new world, and how we want to cater to this whole cloud-native environment which is being created, and make sure people are doing their best work. But regardless, Corey, I mean, this has been an amazing, insightful chat, even for me. And I really appreciate you having me on the show.Corey: No, thank you for joining me. If people want to learn more about what you're up to, and how you think about things, where can they find you? Because I'm also going to go out on a limb and assume you're also probably hiring, given that everyone seems to be these days.Micheal: Well, that is true. And I wasn't planning to make a hiring pitch but I'm glad that you leaned into that one. Yes, we are hiring and you can find me on Twitter at twitter dot com slash M-I-C-H-E-A-L. I am spelled a bit differently, so make sure you can hit me up, and my DMs are open. And obviously, we have all our open roles listed on pinterestcareers.com as well.Corey: And we will, of course, put links to that in the [show notes 00:49:45]. Thank you so much for taking the time to speak with me today. I really appreciate it.Micheal: Thank you, Corey. It was really been great on your show.Corey: And I'm sure we'll do it again in the near future. Micheal Benedict, Head of Engineering Productivity at Pinterest. I am Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a long rambling comment about exactly how many data centers Pinterest could build instead.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

What could be better than putting together Veteran's Week with a Vet who is also an entrepreneur. Gerald Young visited with us several years ago and we thought it would be a good time to catch up on his business Young G's BBQ Sauce. Take a listen to his positive attitude, how his company has grown, what happens when he gets a "no" from a perspective and learn where you can find his sauce. We had a great time sitting outside a Starbucks...and there is a story behind that...as well. Enjoy and..."Git ya some!" Thanks for listening! The award winning Insight on Business the News Hour with Michael Libbie is the only weekday business news podcast in the Midwest. The national, regional and some local business news along with long-form business interviews can be heard Monday - Friday. You can subscribe on PlayerFM, Podbean, iTunes, Spotify, Stitcher or TuneIn Radio. And you can catch The Business News Hour Week in Review each Sunday Noon on News/Talk 1540 KXEL. The Business News Hour is a production of Insight Advertising, Marketing & Communications. You can follow us on Twitter @IoB_NewsHour.

Assaf Krintza joins the JavaScript Jabber panel to discuss the various approaches and uses for state management in web applications. Some of the focus is on React, but many of the tools and approaches work in or have similar options in the other web frameworks. Panel AJ O'NealDan ShappirSteve Edwards Guest Assaf Krintza Sponsors Shortcut (formerly Clubhouse.io)Dev Influencers AcceleratorLevel Up | Devchat.tv Links LivecycleLinkedIn: Assaf Krintza Twitter: Assaf Krintza ( @krinssaf ) Picks AJ- Killers of the Flower MoonAJ- The Stormlight ArchiveAJ- The Lightbringer SeriesAssaf- Shadertoy BetaAssaf- Inigo Quilez - YouTubeDan- Dilvish, the DamnedDan- The Changing LandDan- Hobson's BrowserSteve- A Tunguska sized airburst destroyed Tall el-Hammam a Middle Bronze Age city in the Jordan Valley near the Dead SeaSteve- The wholly pun bible - InstagramSteve- The wholly pun bible - InstagramSteve- GitHub | elijahmanor/devpun Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode )coolaj86- Twitch Contact Dan: GitHub: Dan Shappir ( DanShappir )LinkedIn: Dan ShappirTwitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards Special Guest: Assaf Krintza.

Assaf Krintza joins the JavaScript Jabber panel to discuss the various approaches and uses for state management in web applications. Some of the focus is on React, but many of the tools and approaches work in or have similar options in the other web frameworks. Panel AJ O'NealDan ShappirSteve Edwards Guest Assaf Krintza Sponsors Shortcut (formerly Clubhouse.io)Dev Influencers AcceleratorLevel Up | Devchat.tv Links LivecycleLinkedIn: Assaf Krintza Twitter: Assaf Krintza ( @krinssaf ) Picks AJ- Killers of the Flower MoonAJ- The Stormlight ArchiveAJ- The Lightbringer SeriesAssaf- Shadertoy BetaAssaf- Inigo Quilez - YouTubeDan- Dilvish, the DamnedDan- The Changing LandDan- Hobson's BrowserSteve- A Tunguska sized airburst destroyed Tall el-Hammam a Middle Bronze Age city in the Jordan Valley near the Dead SeaSteve- The wholly pun bible - InstagramSteve- The wholly pun bible - InstagramSteve- GitHub | elijahmanor/devpun Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode )coolaj86- Twitch Contact Dan: GitHub: Dan Shappir ( DanShappir )LinkedIn: Dan ShappirTwitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards Special Guest: Assaf Krintza.

Steph talks about starting a new project and identifying "focused" tests while Chris shares his latest strategy for managing flaky tests. They also ponder the squishy "it depends" side of software and respond to a listener question about testing all commits in a pull request. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. rspec-retry (https://github.com/NoRedInk/rspec-retry) Cassidy Williams - It Depends - GitHub Universe 2021 (https://www.youtube.com/watch?v=aMWh2uLO9OM) Say No To More Process (https://thoughtbot.com/blog/say-no-to-more-process-say-yes-to-trust) StandardRB (https://github.com/testdouble/standard) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: My new computer is due on the fourth. I'm so close. STEPH: On the fourth? CHRIS: On the fourth. STEPH: That's so exciting. CHRIS: And I'm very excited. But no, I don't want to upgrade any software on this computer anymore. Never again shall I update a piece of software on this computer. STEPH: [laughs] CHRIS: This is its final state. And then I will take its soul and move it into the new computer, and we'll go from there. [chuckles] STEPH: Take its soul. [laughs] CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we learn along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. Let's see. It's been kind of a busy week. It's been a busy family week. Utah, my dog, hasn't been feeling well as you know because you and I have chatted off-mic about that a bit. So he is still recovering from something, I don't know what. He's still on most days his normal captain chaos self, but then other days, he's not feeling well. So I'm just keeping a close eye on him. And then I also got some other family illnesses going on. So it has been a busy family week for sure. On the more technical project side, I am wrapping up my current project. So I have one more week, and then I will shift into a new project, which I'm very excited about. And you and I have chatted about this several times. So there's always just that interesting phase where you're trying to wrap up and hand things off and then accomplish last-minute wishlist items for a project before then you start with a new one. So I am currently in that phase. CHRIS: How long were you on this project for? STEPH: It'll be a total of I think eight months. CHRIS: Eight months, that's healthy. That's a bunch. It's always interesting to be on a project for that long but then not longer. There were plenty of three and four-month projects that I did. And you can definitely get a large body of work done. You can look back at it and proudly stare at the code that you have written. But that length of time is always interesting to me because you end up really...for me, when I've had projects that went that long but then not longer, I always found that to be an interesting breaking point. How are you feeling moving on from it? Are you ready for something new? Are you sad to be moving on? Do you feel attached to things? STEPH: It's always a mix. I'm definitely attached to the team, and then there are always lots of things that I'd still love to work on with that team. But then, I am also excited to start something new. That's why I love this role of consulting because then I get to hop around and see new projects and challenges and work with new people. I'm thinking seven to eight months might be a sweet spot for me in terms of the length of a project. Because I find that first month with a project, I'm really still ramping up, I'm getting comfortable, I'm getting in the groove, and I'm contributing within a short amount of time. But I still feel like that first month; I'm getting really comfortable with this new environment that I'm in. And so then I have that first month. And then, at six months, I have more of heads-down time. And I get to really focus and work with a team. And then there's that transition period, and it's nice to know when that's coming up for several weeks, so then I have a couple of weeks to then start working on that transition phase. So eight months might be perfect because then it's like a month for onboarding, ramping up, getting comfortable. And then six months of focus, and then another month of just focusing on what needs to be transitioned so then I can transition off the team. CHRIS: All right. Well, now we've defined it - eight months is the perfect length of a project. STEPH: That's one of the things I like about the Boost team is because we typically have longer engagements. So that was one of the reasons when we were splitting up the teams in thoughtbot that I chose the Boost team because I was like, yeah, I like the six-month-plus project. Speaking of that wishlist, there are little things that I've wanted to make improvements on but haven't really had time to do. There's one that's currently on my mind that I figured I'd share with you in case you have thoughts on it. But I am a big proponent of using the RSpec focus filter for when running tests. So that way, I can just prefix a context it block or describe block with F, and then RSpec I can just run all the tests. But RSpec will only run the tests that I've prefixed with that F focus command., and I love it. But we are running into some challenges with it because right now, there's nothing that catches that in a pull request. So if you commit that focus filter on some of your tests, and then that gets pushed up, if someone doesn't notice it while reviewing your pull request, then that gets merged into main. And all of the tests are still green, but it's only a subset of the tests that are actually running. And so it's been on my mind that I'd love something that's going to notice that, that's going to catch it, something that is not just us humans doing our best but something that's automated that's going to notice it for us. And I have some thoughts. But I'm curious, have you run into something like this? Do you have a way that you avoid things like that from sneaking into the main branch? CHRIS: Interestingly, I have not run into this particular problem with RSpec, and that's because of the way that I run RSpec tests. I almost never use the focus functionality where you actually change the code file to say, instead of it, it is now fit to focus that it. I tend to lean into the functionality where RSpec you can pass it the line number just say, file: and then line number. And RSpec will automatically figure out which either spec or context block or entire file. And also, I have Vim stuff that allows me to do that very easily from the file. It's very rare that I would want to run more than one file. So basically, with that, I have all of the flexibility I need. And it doesn't require any changes to the file. So that's almost always how I'm working in that mode. I really love that. And it makes me so sad when I go to JavaScript test runners because they don't have that. That said, I've definitely felt a very similar thing with ESLint and ESLint yelling at me for having a console.log. And I'm like, ESLint, I'm working here. I got to debug some stuff, so if you could just calm down for a minute. And what I would like is a differentiation between these are checks that should only run in CI but definitely need to run in CI. And so I think an equivalent would be there's probably a RuboCop rule that says disallow fit or disallow any of the focus versions for RSpec. But I only want those to run in CI. And this has been a pain point that I felt a bunch of times. And it's never been painful enough that I put in the effort to fix it. But I really dislike particularly that version of I'm in my editor, and I almost always want there to be no warnings within the editor. I love that TypeScript or ESLint, or other things can run within the editor and tell me what's going on. But I want them to be contextually aware. And that's the dream I've yet to get there. STEPH: I like the idea of ESLint having a work mode where you're like, back off, I am in work mode right now. [chuckles] I understand that I won't commit this. CHRIS: I'm working here. [laughter] STEPH: And I like the idea of a RuboCop. So that's where my mind went initially is like, well, maybe there's a custom cop, or maybe there's an existing one, and I just haven't noticed it yet. But so I'm adding a rule that says, hey, if you do see an fcontext, fdescribe, ffit, something like that, please fail. Please let us know, so we don't merge this in. So that's on my wishlist, not my to-don't list. That one is on my to-do list. CHRIS: I'm also intrigued, though, because the particular failure mode that you're describing is you take what is an entire spec suite, and instead, you focus down to one context block within a given file. So previously, there were 700 specs that ran, and now there are 12. And that's actually something that I would love for Circle or whatever platform you're running your tests on to be like, hey, just as a note, you had been slowly creeping up and had hit a high watermark of roughly 700 specs. And then today, we're down to 12. So either you did some aggressive grooming, or something's wrong. But a heuristic analysis of like, I know sometimes people delete specs, and that's a thing that's okay but probably not this many. So maybe something went wrong there. STEPH: I feel like we're turning CI into this friend at the bar that's like, "Hey, you've had a couple of drinks. I just wanted to check in with you to make sure that you're good." [laughs] CHRIS: Yes. STEPH: "You've had 100 tests that were running and now only 50. Hey, friend, how are you? What's going on?" CHRIS: "This doesn't sound like you. You're normally a little more level-headed." [laughs] And that's the CI that is my friend that keeps me honest. It's like, "Wait, you promised never to overspend anymore, and yet you're overspending." I'm like, "Thank you, CI. You're right; I did say I want the test to pass." STEPH: [laughs] I love it. I'll keep you posted if I figure something out; if I either turn CI into that friend, that lets me know when my behavior has changed in a concerning way, and an intervention is needed. Or, more likely, I will see if there's a RuboCop or some other process that I can apply that will check for this, which I imagine will be fast. I mean, we're very mindful about ensuring our test suite doesn't slow down as we're running it. But I'm just thinking about this out loud. If we add that additional cop, I imagine that will be fast. So I don't think that's too much of an overhead to add to our CI process. CHRIS: If you've already got RuboCop in there, I'm guessing the incremental cost of one additional cop is very small. But yeah, it is interesting. That general thing of I want CI to go fast; I definitely feel that feel. And we're slowly creeping up on the project I'm working on. I think we're at about somewhere between five to six minutes, but we've gotten there pretty quickly where not that long ago; it was only three minutes. We're adding a lot of features specs, and so they are definitely accruing slowdowns in our CI. And they're worth it; I think, because they're so valuable. And they test the whole integration of everything, but it's a thing that I'm very closely watching. And I have a long list of things that I might pursue when I decide it's time for CI to get a haircut, as it were. STEPH: I have a very hot tip for a way to speed up your test, and that is to check if any of your tests have a very long sleep in them. That came up recently [chuckles] this week where someone was working in a test and found some relic that had been added a while back that then wasn't caught. And I think it was a sleep 30. And they were like, "Hey, I just sped up our test by 30 seconds." I was like, ooh, we should grep now to see if there's anything else like that. [laughs] CHRIS: Oh, I love the sentence we should grep now. [laughter] The correct response to this is to grep immediately. I thought you were going to go with the pro tip of you can just focus down to one context block. And then the specs will run so much faster because you're ignoring most of them, but we don't want to do that. The sleep, though, that's a pro tip. And that does feel like a thing that there could be a cop for, like, never sleep more than...frankly, let's try not to sleep at all but also, add a sleep in our specs. We can sleep in life; it's important, but anyway. [chuckles] STEPH: [laughs] That was the second hot tip, and you got it. CHRIS: Lots of hot tips. Well, I'm going to put this in the category of good idea, terrible idea. I won't call it a hot tip. It's a thing we're trying. So much as we have tried to build a spec suite that is consistent and deterministic and tells us only the truth, feature specs, even in our best efforts, still end up flaking from time to time. We'll have feature specs that fail, and then eventually, on a subsequent rerun, they will pass. And I am of the mindset that A, we should try and look into those and see if there is a real cause to it. But sometimes, just the machinery of feature specs, there's so much going on there. We've got the additional overhead of we're running it within a JavaScript context. There's just so much there that...let me say what I did, and then we can talk more about the context. So there's a gem called RSpec::Retry. It comes from the wonderful folks over at NoRedInk, a well-known Elm shop for anyone out there in the Elm world. But RSpec::Retry does basically what it says in the name. If the spec fails, you can annotate specs. In our case, we've only enabled this for the feature specs. And you can tell it to retry, and you can say, "Retry up to this many times," and et cetera, et cetera. So I have enabled this for our feature specs. And I've only enabled it on CI. That's an important distinction. This does not run locally. So if you run a feature spec and it fails locally, that's a good chance for us to intervene and look at whether or not there's some flakiness there. But on CI, I particularly don't want the case where we have a pull request, everything's great, and we merge that pull request, and then the subsequent rebuild, which again, as a note, I would rather that Circle not rebuild it because we've already built that one. But that is another topic that I have talked about in the past, and we'll probably talk about it again in the future. But setting that aside, Circle will rebuild on the main branch when we merge in, and sometimes we'll see failures there. And that's where it's most painful. Like, this is now the deploy queue. This is trying to get this out into whatever environment we're deploying to. And it is very sad when that fails. And I have to go in and manually say, hey, rebuild. I know that this works because it just worked in the pull request, and it's the same commit hash. So I know deterministically for reasons that this should work. And then it does work on a rebuild. So we introduced RSpec::Retry. We have wrapped it around our feature specs. And so now I believe we have three possible retries. So if it fails once, it'll try it again, and then it'll try it a third time. So far, we've seen each time that it has had to step in; it will pass on the subsequent run. But I don't know; there was some very gentle pushback or concerns; let's call them when I introduced this pull request from another developer on the team, saying, "I don't know, though, I feel like this is something that we should solve at the root layer. The failures are a symptom of flaky tests, or inconsistency or et cetera, and so I'd rather not do this." And I said, "Yeah, I know. But I'm going to merge it," and then I merged it. We had a better conversation about that. I didn't just broadly overrule. But I said, "I get it, but I don't see the obvious place to shore this up. I don't see where we're doing weird inconsistent things in our code. This is just, I think, inherent complexity of feature specs." So I did it, but yeah, good idea, terrible idea. What do you think, Steph? Maybe terrible is too strong of a word. Good idea, mediocre idea. STEPH: I like the original branding. I like the good idea, terrible idea. Although you're right, that terrible is a very strong branding. So I am biased right now, so I'm going to lead in answering your question by stating that because our current project has that problem as well where we have these flaky tests. And it's one of those that, yes, we need to look at them. And we have fixed a large number of them, but there are still more of them. And it becomes a question of are we actually doing something wrong here that then we need to fix? Or, like you said, is it just the nature of these features-specs? Some of them are going to occasionally fail. What reasonable improvements can we make to address this at the root cause? I'm interested enough that I haven't heard of RSpec::Retry that I want to check it out because when you add that, you annotate a test. When a test fails, does it run the entire build, or will it rerun just that test? Do you happen to know? CHRIS: Just the test. So it's configured as in a round block on the feature specs. And so you tell it like, for any feature spec, it's like config.include for feature specs RSpec::Retry or whatever. So it's just going to rerun the one feature spec that failed when and if that happens. So it's very, very precise as well in that sense where when we have a failure merging into the main branch, I have to rebuild the whole thing. So that's five or six minutes plus whatever latency for me to notice it, et cetera, whereas this is two more seconds in our CI runtime. So that's great. But again, the question is, am I hiding? Am I dealing with the symptoms and not the root cause, et cetera? STEPH: Is there a report that's provided at the end that does show these are the tests that failed and we had to rerun them? CHRIS: I believe no-ish. You can configure it to output, but it's just going to be outputting to standard out, I believe. So along with the sea of green dots, you'll see had to retry this one. So it is visible, but it's not aggregated. And the particular thing is there's the JUnit reporter that we're using. So the XML common format for this is how long our tests took to run, and these ones passed and failed. So Circle, as a particular example, has platform-level insights for that kind of stuff. And they can tell you these are your tests that fail most commonly. These are the tests that take the longest run, et cetera. I would love to get it integrated into that such that retried and then surface this to Circle. Circle could then surface it to us. But right now, I don't believe that's happening. So it is truly I will not see it unless I actively go search for it. To be truly honest, I'm probably not doing that. STEPH: Yeah, that's a good, fair, honest answer. You mentioned earlier that if you want a test to retry, you have to annotate the test. Does that mean that you get to highlight specific tests that you're marking those to say, "Hey, I know that these are flaky. I'm okay with that. Please retry them." Or does it apply to all of them? CHRIS: I think there are different ways that you can configure it. You could go the granular route of we know this is a flaky spec, so we're going to only put the retry logic around it. And that would be a normal RSpec annotation sort of tagging the spec, I think, is the terminology there. But we've configured it globally for all feature specs. So in a spec support file, we just say config.include Rspec::Retry where type is a feature. And so every feature spec now has the possibility to retry. If they pass on the first pass, which is the hope most of the time, then they will not be tried. But if they don't, if they fail, then they'll be retried up to three times or up to two additional times, I think is the total. STEPH: Okay, cool. That's helpful. So then I think I have my answer. I really think it's a good idea to automate retrying tests that we have identified that are flaky. We've tried to address the root, and our resolution was this is fine. This happens sometimes. We don't have a great way to improve this, and we want to keep the test. So we're going to highlight that this test we want to retry. And then I'm going to say it's not a great idea to turn it on for all of them just because then I have that same fear about you're now hiding any flaky tests that get introduced into the system. And nobody reasonably is going to go and read through to see which tests are going to get retried, so that part makes me nervous. CHRIS: I like it. I think it's a balanced and reasonable set of good and terrible idea. Ooh, it's perfect. I don't think we've had a balanced answer on that yet. STEPH: I don't think so. CHRIS: This is a new outcome for this segment. I agree. Ideally, in my mind, it would be getting into that XML format, the output from the tests, so that we now have this artifact, we can see which ones are flaky and eventually apply effort there. What you're saying feels totally right of we should be more particular and granular. But at the same time, the failure mode and the thing that I'm trying, I want to keep deploys going. And I only want to stop deploys if something's really broken. And if a spec retries, then I'm fine with it is where I've landed, particularly because we haven't had any real solutions where there was anything weird in our code. Like, there's just flakiness sometimes. As I say it, I feel like I'm just giving up. [laughs] And I can hear this tone of stuff's just hard sometimes, and so I've taken the easy way out. And I guess that's where I'm at right now. But I think what you're saying is a good, balanced answer here. I like it. I don't know if I'm going to do anything about it, but...[laughter] STEPH: Well, going back to when I was saying that I'm biased, our team is feeling this pain because we have flaky tests. And we're creating tickets, and we're trying to do all the right things. We create a ticket. We have that. So it's public. So people know it's been acknowledged. If someone's working on it, we let the team know; hey, I'm working on this. So we're not duplicating efforts. And so, we are trying to address all of them. But then some of them don't feel like a great investment of our time trying to improve. So that's what I really do like about the RSpec::Retry is then you can still have a resolution. Because it's either right now your resolution is to fix it or to change the code, so then maybe you can test it in a different way. There's not really a good medium step there. And so the retry feels like an additional good outcome to add to your tool bag to say, hey, I've triaged this, and this feels reasonable that we want to retry this. But then there's also that concern of we don't want to hide all of these flaky tests from ourselves in case we have done it and there is an opportunity for us to improve it. So I think that's what I do really like about it because right now, for us, when a test fails, we have to rerun the entire build, and that's painful. So if tests are taking about 20 minutes right now, then one spec fails, and then you have to wait another 20 minutes. CHRIS: I would have turned this on years ago with a 20-minute build time. [chuckles] STEPH: [laughs] Yeah, you're not wrong. But also, I didn't actually know about RSpec::Retry until today. So that may be something that we introduce into our application or something that I bring up to the team to see if it's something that we want to add. But it is interesting that initial sort of ooh kind of feeling that the team will give you introducing because it feels bad. It feels wrong to be like, hey, we're just going to let these flaky tests live on, and we're going to automate retrying them to at least speed us up. And it's just a very interesting conversation around where we want to invest our time and between the risk and pay off. And I had a similar experience this week where I had that conversation, but this one was more with myself where I was working through a particular issue where we have a state in the application where something weird was done in the past that led us to a weird state. And so someone raised a very good question where it's like, well, if what you're saying is technically an impossible state, we should make it impossible, like at the database layer. And I love that phrase. And yet, there was a part of me that was like, yes, but also doing that is not a trivial investment. And we're here because of a very weird thing that happened before. It felt one of those interesting, like, do we want to pursue the more aggressive, like, let's make this impossible for the future? Or do we want to address it for now and see if it comes back up, and then we can invest more time in it? And I had a hard time walking myself through that because my initial response was, well, yeah, totally, we should make it impossible. But then I walked through all the steps that it would take to make that happen, and it was not very trivial. And so it was one of those; it felt like the change that we ended up with was still an improvement. It was going to prevent users from seeing an error. It was still going to communicate that this state is an odd state for the application to be in. But it didn't go as far as to then add in all of the safety measures. And I felt good about it. But I had to convince myself to feel good about it. CHRIS: What you're describing there, the whole thought sequence, really feels like the encapsulation of it depends. And that being part of the journey of learning how to do software development and what it means. And you actually shared a wonderful video with me yesterday, and it was Cassidy Williams at GitHub Universe. And it was her talking to her younger self, and just it depends, and it was so true. So we will include a link to that in the show note because that was a wonderful thing for you to share. And it really does encapsulate this thing. And from the outside, before I started doing software development, I'm like, it's cool. I'm going to learn how to sling code and fix the stuff and hack, and it'll be great, and obvious, and correct, and knowable. And now I'm like, oh man, squishy nonsense. That's all it is. STEPH: [laughs] CHRIS: Fun squishy, and I like it. It's so good. But it depends. Exactly that one where you're like, I know that there's a way to get to correctness here but is it worth the effort? And looping back to...I'm surprised at the stance that I've taken where I'm just like, yeah, I'm putting in RSpec::Retry. This feels like the right thing. I feel good about this decision. And so I've tried to poke at it a tiny bit. And I think what matters to me deeply in a list of priorities is number one correctness. I care deeply that our system behaves correctly as intended and that we are able to verify that. I want to know if the system is not behaving correctly. And that's what we've talked about, like, if the test suite is green, I want to be able to deploy. I want to feel confident in that. Flaky specs exist in this interesting space where if there is a real underlying issue, if we've architected our system in a way that causes this flakiness and that a user may ever experience that, then that is a broken system. That is an incorrect system, and I want to resolve that. But that's not the case with what we're experiencing. We're happy with the architecture of our system. And when we're resolving it, we're not even really resolving them. We're just rerunning manually at this point. We're just like, oh, that spec flaked. And there's nothing to do here because sometimes that just happens. So we're re-running manually. And so my belief is if I see all green, if the specs all pass, I know that I can deploy to production. And so if occasionally a spec is going to flake and retrying it will make it pass (and I know that pass doesn't mean oh, this time it happened to pass; it's that is the correct outcome) and we have a false negative before, then I'm happy to instrument the system in a way that hides that from me because, at this point, it does feel like noise. I'm not doing anything else with the failures when we were looking at them more pointedly. I'm not resolving those flaky specs. There are no changes that we've made to the underlying system. And they don't represent a failure mode or an incorrectness that an end-user might see. So I honestly want to paper over and hide it from myself. And that's why I've chosen this. But you can see I need to defend my actions here because I feel weird. I feel a little off about this. But as I talk through it, that is the hierarchy. I care about correctness. And then, the next thing I care about is maintaining the deployment pipeline. I want that to be as quick and as efficient as possible. And I've talked a bunch about explorations into the world of observability and trying to figure out how to do continuous deployment because I think that really encourages overall better engineering outcomes. And so first is correctness. Second is velocity. And flaky specs impact velocity heavily, but they don't actually impact correctness in the particular mode that we're experiencing them here. They definitely can. But in this case, as I look at the code, I'm like, nah, that was just noise in the system. That was just too much complexity stacked up in trying to run a feature spec that simulates a browser and a user clicking in JavaScript and all this stuff and the things. But again, [laughs] here I am. I am very defensive about this apparently. STEPH: Well, I can certainly relate because I was defending my answer to myself earlier. And it is really interesting what you're pointing out. I like how you appreciate correctness and then velocity, that those are the two things that you're going after. And flaky tests often don't highlight an incorrect system. It is highlighting that maybe our code or our tests are not as performant as we would like them to be, but the behavior is correct. So I think that's a really important thing to recognize. The part where I get squishy is where we have encountered on this project some flaky tests that did highlight that we had incorrect behavior, and there's only been maybe one or two. It was rare that it happened, but it at least has happened once or twice where it highlighted something to us that when tests were run...I think there's a whole lot of context. I won't get into it. But essentially, when tests were being run in a particular way that made them look like a flaky test, it was actually telling us something truthful about the system, that something was behaving in a way that we didn't want it to behave. So that's why I still like that triage that you have to go through. But I also agree that if you're trying to get out at a deploy, you don't want to have to deal with flaky tests. There's a time to eat your vegetables, and I don't know if it's when you've got a deploy that needs to go out. That might not be the right time to be like, oh, we've got a flaky test. We should really address this. It's like, yes; you should note to yourself, hey, have a couple of vegetables tomorrow, make a ticket, and address that flaky test but not right now. That's not the time. So I think you've struck a good balance. But I also do like the idea of annotating specific tests instead of just retrying all of them, so you don't hide anything from yourself. CHRIS: Yeah. And now that I'm saying it and now that I'm circling back around, what I'm saying is true of everything we've done so far. But it is possible that now this new mode that the system behaves in where it will essentially hide flaky specs on CI means that any new flaky regressions, as it were, will be hidden from us. And thus far, almost all or I think all of the flakiness that we've seen has basically been related to timeouts. So a different way to solve this would potentially be to up the Capybara wait time. So there are occasionally times where the system's churning through, and the various layers of the feature specs just take a little bit longer. And so they miss...I forget what it is, but it's like two seconds right now or something like that. And I can just bump that up and say it's 10 seconds. And that's a mode that if eventually, the system ends in the state that we want, I'm happy to wait a little longer to see that, and that's fine. But there are...to name some of the ways that flaky tests can actually highlight truly incorrect things; race conditions are a pretty common one where this behaves fine most of the time. But if the background job happens to succeed before the subsequent request happens, then you'll go to the page. That's a thing that a real user may experience, and in fact, it might even be more likely in production because production has differential performance characteristics on your background jobs versus your actual application. And so that's the sort of thing that would definitely be worth keeping in mind. Additionally, if there are order issues within your spec suite if the randomize...I think actually RSpec::Retry wouldn't fix this, though, because it's going to retry within the same order. So that's a case that I think would be still highlighted. It would fail three times and then move on. But those we should definitely deal with. That's a test-related thing. But the first one, race conditions, that's totally a thing. They come up all the time. And I think I've potentially hidden that from myself now. And so, I might need to lock back what I said earlier because I feel like it's been true thus far that that has not been the failure mode, but it could be moving forward. And so I really want to find out if we got flaky specs. I don't know; I feel like I've said enough about this. So I'm going to stop saying anything new. [laughs] Do you have any other thoughts on this topic? STEPH: Our emotions are a pendulum. We swing hard one way, and then we have to wait till we come back and settle in the middle. But there's that initial passion play where you're really frustrated by something, and then you swing, and you settle back towards something that's a little more neutral. CHRIS: I don't trust anyone who pretends like their opinions never change. It doesn't feel like a good way to be. STEPH: Oh, I hope that...Do people say that? I hope that's not true. I hope we are all changing our opinions as we get more information. CHRIS: Me too. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. CHRIS: Well, shifting only ever so slightly because it turns out it's a very related question, but we have a listener question. As always, thank you so much to everyone who sends in listener questions. We really appreciate them. And today's question comes from Mikhail, and he writes in, "Regarding the discussion in Episode 311 on requiring commits merged to be tested, I have a question on how you view multi commit PRs. Do you think all the commits in a PR should be tested or only the last one? If you test all commits in a PR, do you have any good tips on setups for that? Would you want all commits to pass all tests? For one, it helps a lot when using Git bisect. It is also a question of keeping the history clean and understandable. As a background on the project I currently work on, we have the opinion that all commits should be tested and working. We have now decided on single commit PRs only since this is the only way that we can currently get the setup reasonably on our CI. I would like to sometimes make PRs with more than one commit since I want to make commits as small as possible. In order to do that, we would have to find a way to make sure all commits in the PR are tested. There seems to be some hacky ways to accomplish this, but there is not much talk about it. Also, we are strict in requiring a linear history in all our projects. Kind regards, Mikhail." So, Steph, what do you think? STEPH: I remember reading this question when it came in. And I have an experience this week that is relevant to this mainly because I had seen this question, and I was thinking about it. And off the cuff, I haven't really thought about this. I haven't been very concerned about ensuring every single commit passes because I want to ensure that, ultimately, the final commit that I have is going in. But I also rarely have more than one commit in a PR. So that's often my default mode. There are a couple of times that I'll have two, maybe three commits, but I think that's pretty rare for me. I'll typically have just one commit. So I haven't thought about this heavily. And it's not something that frankly I've been concerned about or that I've run into issues with. From their perspective about using Git bisect, I could see how that could be troublesome, like if you're looking at a commit and you realize there's a particular commit that's already merged and that fails. The other area that I could think of where this could be problematic is if you're trying to roll back to a specific commit. And if you accidentally roll back to a commit that is technically broken, but you didn't know that because it was not the final commit as was getting tested on CI, that could happen. I haven't seen that happen. I haven't experienced it. So while that does seem like a legitimate concern, it's also one that I frankly just haven't had. But because I read this question from this person earlier this week, I actually thought about it when I was crafting a PR that had several commits in it, which is kind of unusual for me since I'm usually one or two commits in a PR. But for this one, I had several because we use standard RB in our project to handle all the formatting. And right now, we have one of those standard to-do files because we added it to the project. But there are still a number of manual fixes that need to be applied. So we just have this list of files that still need to be formatted. And as someone touches that file, we will format it, and then we'll take it out of that to-do list. So then standard RB will include it as it's linting all of our files. And I decided to do that for all of our spec files. Because I was like, well, this was the safest chunk of files to format that will require the least amount of review from folks. So I just want to address all of them in one go. But I separated the more interesting changes into different commits just to make others aware of, like, hey, this is something standard RB wants. And it was interesting enough that I thought I would point it out. So my first commit removed all the files from that to-do list, but then my other commits are the ones that made actual changes to some of those files that needed to be corrected. So technically, one or two of my middle commits didn't pass the standard RB linting. But because CI was only running that final commit, it didn't notice that. And I thought about this question, and so I intentionally went back and made sure each of those commits were correct at that point in time. And I feel good about that. But I still don't feel the need to add more process around ensuring each commit is going to be green. I think I would lean more in favor of let's keep our PR small to one or two commits. But I don't know; it's something I haven't really run into. It's an interesting question. How about you? What are your experiences, or what are your thoughts on this, Chris? CHRIS: When this question came through, I thought it was such an interesting example of considering the cost of process changes. And to once again reference one of our favorite blog posts by German Velasco, the Say No to More Process post, which we will, of course, link in the show notes. This is such a great example of there was likely a small amount of pain that was felt at one point where someone tried to run git bisect. They ran into a troublesome commit, and they were like, oh no, this happened. We need to add processes, add automation, add control to make sure this never happens again. Personally, I run git bisect very rarely. When I do, it's always a heroic moment just to get it started and to even know which is the good and which is the bad. It's always a thing anyway. So it would be sad if I ran into one of these commits. But I think this is a pretty rare outcome. I think in the particular case that you're talking about, there's probably a way to actually tease that apart. I think it sounds like you fixed those commits knowing this, maybe because you just put it in your head. But the idea that the process that this team is working on has been changed such that they only now allow single commit PRs feels like too much process in my mind. I think I'm probably 80%, maybe 90% of the time; it's only a single commit in a PR for me. But occasionally, I really value having the ability to break it out into discrete steps, like these are all logically grouped in one changeset that I want to send through. But they're discrete steps that I want to break apart so that the team can more easily review it so that we have granular separation, and I can highlight this as a reference. That's often something that I'll do is I want this commit to standalone because I want it to be referenced later on. I don't want to just fold it into the broader context in which it happened, but it's pretty rare. And so to say that we can't do that feels like we're adding process where it may not be worth it, where the cost of that process change is too high relative to the value that we're getting, which is speculatively being able to run git bisect and not hit something problematic in the future. There's also the more purist, dogmatic view of well, all commits should be passing, of course. Yeah, I totally agree with that. But what's it worth to you? How much are you willing to spend to achieve that goal? I care deeply about the correctness of my system but only the current correctness. I don't care about historical correctness as much, some. I think I'm diminishing this more than I mean to. But really back to that core question of yes, this thing has value, but is it worth the cost that we have to pay in terms of process, in terms of automation and maintenance of that automation over time, et cetera or whatever the outcome is? Is it worth that cost? And in this case, for me, this would not be worth the cost. And I would not want to adopt a workflow that says we can only ever have single commit PRs, or all commits must be run on CI or any of those variants. STEPH: This is an interesting situation where I very much agree with everything you're saying. But I actually feel like what Mikhail wants in this world; I want it too. I think it's correct in the way that I do want all the commits to pass, and I do want to know that. And I think since I do fall into the default, like you mentioned, 80%, 90% of my PRs are one commit. I just already have that. And the fact that they're enforcing that with their team is interesting. And I'm trying to think through why that feels cumbersome to enforce that. And I'm with you where I'll maybe have a refactor commit or something that goes before. And it's like, well, what's wrong with splitting that out into a separate PR? What's the pain point of that? And I think the pain point is the fact that one, you have two PRs that are stacked on each other. So you have the first one that you need to get reviewed, and then the second one; there's that bit of having to hop between the two if there's some shared context that someone can't just easily review in one pull request. But then there's also, as we just mentioned, there's CI that has to run. And so now it's running on both of them, even though maybe that's a good thing because it's running on both commits. I like the idea that every commit is tested, and every commit is green. But I actually feel like it's some of our other processes that make it cumbersome and hard to get there. And if CI did run on every commit, I think it would be ideal, but then we are increasing our CI time by running it on every commit. And then it comes down to essentially what you said, what's the risk? So if we do merge in a commit that doesn't work or has something that's failing about it but then the next commit after that fixes it, what's the risk that we're going to roll back to that one specific commit that was broken? If that's a high risk for you and your team, then adding this process is probably the really wise thing to do because you want to make sure the app doesn't go down for users. That's incredibly important. If that's not a high risk for your team, then I wouldn't add the process. CHRIS: Yeah, I totally agree. And to clarify my stances, for me, this change, this process change would not be worth the trade-off. I love the idea. I love the goal of it. But it is not worth the process change, and that's partly because I haven't particularly felt the pain. CI is not an inexhaustible resource I have learned. I'm actually somewhat proud our very small team that is working on the project that we're working on; we just recently ran out of our CI budget, and Circle was like, "Hey, we got to charge you more." And I was like, "Cool, do that." But it was like, there is cost both in terms of the time, clock time, and each PR running and all of those. We have to consider all of these different things. And hopefully, we did a useful job of framing the conversation, because as always, it depends, but it depends on what. And in this case, there's a good outcome that we want to get to, but there's an associated cost. And for any individual team, how you weigh the positive of the outcome versus how you weigh the cost will alter the decision that you make. But that's I think, critically, the thing that we have to consider. I've also noticed I've seen this conversation play out within teams where one individual may acutely feel the pain, and therefore they're anchored in that side. And the cost is irrelevant to them because they're like, I feel this pain so acutely, but other people on the team aren't working in that part of the codebase or aren't dealing with bug triage in the same way that that other developer is. And so, even within a team, there may be different levels of how you measure that. And being able to have meaningful conversations around that and productively come to a group decision and own that and move forward with that is the hard work but the important work that we have to do. STEPH: Yeah. I think that's a great summary; it depends. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Actualizar plugins o temas personalizados suele ser una de las dudas más habituales cuando se desarrolla. ¿Se puede hacer con Git? Sí. ¿Es recomendable hacerlo en producción? Quizá no.

In this TCP Talks episode, Justin Brodley and Jonathan Baker talk with Jonathan Heiliger, co-founder and partner at Vertex Ventures: an early-stage venture capital firm backing innovative technology entrepreneurs.  Earlier in his career, at just 19, Jonathan co-founded web hosting provider GlobalCenter and served as CTO. He went on to hold engineering roles at Walmart and Danger, Inc., the latter of which was acquired by Microsoft. He was also Vice President of Infrastructure and Operations at Facebook (now Meta), and a general partner at North Bridge Ventures. The latter firm's portfolio included Quora, Periscope, and Lytro (which has been acquired by Google.) At Vertex Ventures, Jonathan has helped cutting-edge companies like LaunchDarkly and OpsLevel revolutionize the tech space with continuous delivery and IT service management solutions. Jonathan shares his insights into the shifting market of IT services and explains why decentralizing infrastructure management can help digitally native companies operate at a faster pace. According to Jonathan, the question of IT service infrastructure isn't being adequately addressed. Without properly defining service ownership, businesses looking to scale run the risk of siloing critical knowledge, and losing track of services networks.  Jonathan also discusses his own experiences running infrastructure at Facebook (oops, Meta), the merits of both centralized and decentralized IT services management, and how he and his partners at Vertex Ventures approach new investments.   Featured Guest

About Betty Betty Junod is the Senior Director of Multi-Cloud Solutions at VMware helping organizations along their journey to cloud. This is her second time at VMware, having previously led product marketing for end user computing products.  Prior to VMware she held marketing leadership roles at Docker and solo.io in following the evolution of technology abstractions from virtualization, containers, to service mesh. She likes to hang out at the intersection of open source, distributed systems, and enterprise infrastructure software. @bettyjunod  Links: Twitter: https://twitter.com/BettyJunod Vmware.com/cloud: https://vmware.com/cloud 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: You know how git works right?Announcer: Sorta, kinda, not really Please ask someone else!Corey: Thats all of us. Git is how we build things, and Netlify is one of the best way I've found to build those things quickly for the web. Netlify's git based workflows mean you don't have to play slap and tickle with integrating arcane non-sense and web hooks, which are themselves about as well understood as git. Give them a try and see what folks ranging from my fake Twitter for pets startup, to global fortune 2000 companies are raving about. If you end up talking to them, because you don't have to, they get why self service is important—but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y.comCorey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Periodically, I like to poke fun at a variety of different things, and that can range from technologies or approaches like multi-cloud, and that includes business functions like marketing, and sometimes it extends even to companies like VMware. My guest today is the Senior Director of Multi-Cloud Solutions at VMware, so I'm basically spoilt for choice. Betty Junod, thank you so much for taking the time to speak with me today and tolerate what is no doubt going to be an interesting episode, one way or the other.Betty: Hey, Corey, thanks for having me. I've been a longtime follower, and I'm so happy to be here. And good to know that I'm kind of like the ultimate cross-section of all the things [laugh] that you can get snarky about.Corey: The only thing that's going to make that even better is if you tell me, “Oh, yeah, and I moonlight on a contract gig by naming AWS services.” And then I just won't even know where to go. But I'll assume they have to generate those custom names in-house.Betty: Yes. Yes, I think they do those there. I may comment on it after the fact.Corey: So, periodically I am, let's call it miscategorized, in my position on multi-cloud, which is that it's a worst practice that when you're designing something from scratch, you should almost certainly not be embracing unless you're targeting a very specific corner case. And I stand by that, but what that has been interpreted as by the industry, in many cases because people lack nuance when you express your opinions in tweet-sized format—who knew—as me saying, “Multi-cloud bad.” Maybe, maybe not. I'm not interested in assigning value judgment to it, but the reality is that there are an awful lot of multi-cloud deployments out there. And yes, some of them started off as, “We're going to migrate from one to the other,” and then people gave up and called it multi-cloud, but it is nuanced. VMware is a company that's been around for a long time. It has reinvented itself in a few different ways at different periods of its evolution, and it's still highly relevant. What is the Multi-Cloud Solutions group over at VMware? What do you folks do exactly?Betty: Yeah. And so I will start by multi-cloud; we're really taking it from a position of meeting the customer where they are. So, we know that if anything, the only thing that's a given in our industry is that there will be something new in the next six months, next year, and the whole idea of multi-cloud, from our perspective, is giving customers the optionality, so don't make it so that it's a closed thing for them. But if they decide—it's not that they're going to start, “Hey, I'm going to go to cloud, so day one, I'm going to go all-in on every cloud out there.” That doesn't make sense, right, as—Corey: But they all gave me such generous free credit offers when I founded my startup; I feel obligated to at this point.Betty: I mean, you can definitely create your account, log in, play around, get familiar with the console, but going from zero to being fully operationalized team to run production workloads with the same kind of SLAs you had before, across all three clouds—what—within a week is not feasible for people getting trained up and actually doing that. Our position is that meeting customers where they are and knowing that they may change their mind, or something new will come up—a new service—and they really want to use a new service from let's say GCP or AWS, they want to bring that with an application they already have or build a new app somewhere, we want to help enable that choice. And whether that choice applies to taking an existing app that's been running in their data center—probably on vSphere—to a new place, or building new stuff with containers, Kubernetes, serverless, whatever. So, it's all just about helping them actually take advantage of those technologies.Corey: So, it's interesting to me about your multi-cloud group, for lack of a better term, is there a bunch of things fall under its umbrella? I believe Bitnami does—or as I insist on calling it, ‘bitten-A-M-I'—I believe that SaltStack—which I wrote a little bit of once upon a time, which tells me you folks did no due diligence whatsoever because everything I've ever written is molten garbage—Betty: Not [unintelligible 00:04:33].Corey: And—so to be clear, SaltStack is good; just the parts that I wrote are almost certainly terrible because have you met me?Betty: I'll make a note. [laugh].Corey: You have Wavefront, you have CloudHealth, you have a bunch of other things in the portfolio, and yeah, all those things do work across multiple clouds, but there's nothing that makes using any of those things a particularly bad idea even if you're all-in on one cloud provider, too. So, it's a portfolio that applies to a whole bunch have different places from your perspective, but it can be used regardless of where folks stand ideologically.Betty: Yes. So, this goes back to the whole idea that we meet the customers where they are and help them do what they want to do. So, with that, making sure these technologies that we have work on all the clouds, whether that be in the data center or the different vendors, so that if a customer wants to just use one, or two, or three, it's fine. That part's up to them.Corey: The challenge I've run into is that—and maybe this is a ‘Twitter Bubble' problem, but unfortunately, having talked to a whole bunch of folks in different contexts, I know it isn't—there's almost this idea that you have to be incredibly dogmatic about a particular technology that you're into. I joke periodically about the Rust Evangelism Strikeforce where their entire job is talking about using Rust; their primary IDE is PowerPoint because they're giving talks all the time about it rather than writing code. And great, that's a bit of an exaggeration, but there are the idea of a technology purist who is taking, “Things must be this way,” well past a point of being reasonable, and disregarding the reality that, yeah, the world is messy in a way that architectural diagrams never are.Betty: Yeah. The architectural diagrams are always 2D, right? Back to that PowerPoint slide: how can I make pretty boxes? And then I just redraw a line because something new came out. But you and I have been in this industry for a long time, there's always something new.And I think that's where the dogmatism gets problematic because if you say we're only going to do containers this way—you know, I could see Swarm and Kubernetes, or all-in on AWS and we're going to use all the things from AWS and there's only this way. Things are generational and so the idea that you want to face the reality and say that there is a little bit of everything. And then it's kind of like, how do you help them with a part of that? As a vendor, it could be like, “I'm going to help us with a part of it, or I'm going to help address certain eras of it.” That's where I think it gets really bad to be super dogmatic because it closes you off to possibly something new and amazing, new thinking, different ways to solve the same problem.Corey: That's the problem is left to our own devices, most of us who are building things, especially for random ideas, yeah, there's a whole modern paradigm of how I can build these things, but I'm going to shortcut to the thing I know best, which may very well the architectures that I was using 15 years ago, maybe tools that I was using 15 years ago. There's a reason that Vim is still as popular as it is. Would I recommend it to someone who's a new user? Absolutely not; it's user-hostile, but back in my days of being a grumpy sysadmin, you learned vi because it was on everything you could get into, and you never knew in what environment you were going to be encountering stuff. These days, you aren't logging in to remote systems to manage them, in most cases, and when it happens, it's a rarity and a bug.The world changes; different approaches change, but you have to almost reinvent your entire philosophy on how things work and what your career trajectory looks like. And you have to give up aspects of what you've considered to be part of your identity and embrace something new. It was hard for me to accept that, for example, Docker and the wave of containerization that was rolling out was effectively displacing the world that I was deep in of configuration management with Puppet and with Salt. And the world changes; I said, “Okay, now I'll work on cloud.” And if something else happens, and mainframes are coming back again, instead, well, I'm probably not going to sit here railing against the tide. It would be ridiculous to do that from my perspective. But I definitely understand the temptation to fight against it.Betty: Mm-hm. You know, we spend so much time learning parts of our craft, so it's hard to say, “I'm now not going to be an expert in my thing,” and I have to admit that something else might be better and I have to be a newbie again. That can be scary for someone who's spent a lot of time to be really well-versed in a specific technology. It's funny that you bring up the whole Docker and Puppet config management; I just had a healthy discussion over Slack with some friends. Some people that we know and comment about some of the newer areas of config management, and the whole idea is like, is it a new category or an evolution of? And I went back to the point that I made earlier is like, it's generations. We continually find new ways to solve a problem, and one thing now is it [sigh] it just all goes so much faster, now. There's a new thing every week. [laugh] it seems sometimes.Corey: It is, and this is the joy of having been in this industry for a while—toxic and broken in many ways though it is—is that you go through enough cycles of seeing today's shiny, new, amazing thing become tomorrow's legacy garbage that we're stuck supporting, which means that—at least from my perspective—I tend to be fairly conservative with adopting new technologies with respect to things that matter. That means that I'm unlikely to wind up looking at the front page of Hacker News to pick a framework to build a banking system in, and I'm unlikely to be the first kid on my block to update to a new file system or database, just because, yeah, if I break a web server, we all laugh, we make fun of the fact that it throws an error for ten minutes, and then things are back up and running. If I break the database, there's a terrific chance that we don't have a company anymore. So, it's the ‘mistakes will show' area and understanding when to be aggressive and when to hold back as far as jumping into new technologies is always a nuanced decision. And let's be clear as well, an awful lot of VMware's customers are large companies that were founded, somehow—this is possible—before 2010. Imagine that. Did people—Betty: [laugh]. I know, right?Corey: —even have businesses or lives back then? I thought we all used horse-driven carriages and whatnot. And they did not build on cloud—not because of any perception of distrust; because it functionally did not exist at the time that they were building these things. And, “Oh, come out into the cloud. It's fine now.” It… yeah, that application is generating hundreds of millions in revenue every quarter. Maybe we treat that with a little bit of respect, rather than YOLO-ing it into some Lambda-driven monster that's constructed—Betty: One hundred—Corey: —out of popsicle sticks and glue.Betty: —percent. Yes. I think people forget that. And it's not that these companies don't want to go to cloud. It's like, “I can't break this thing. That could be, like, millions of dollars lost, a second.”Corey: I write my weekly newsletters in a custom monstrosity of a system that has something like 30-some-odd Lambda functions, a bunch of API gateways that are tied together with things, and periodically there are challenges with it that break as the system continues to evolve. And that's fine. And I'm okay with using something like that as a part of my workflow because absolute worst case, I can go back to the way that my newsletter was originally written: in Google Docs, and it doesn't look anywhere near the same way, and it goes back to just a text email that starts off with, “I have messed up.” And that would be a better story than most of the stuff I put out as a common basis. Similarly, yeah, durability is important.If this were a serious life-critical app, it would not just be hanging out in a single region of a single provider; it would probably be on one provider, as I've talked about, but going multi-region and having backups to a different cloud provider. But if AWS takes a significant enough outage to us-west-2 in Oregon, to the point where my ridiculous system cannot function to write the newsletter, that too, is a different handwritten email that goes out that week because there's no announcement they've made that anyone's going to give the slightest toss about, given the fact that it's basically Cloud Armageddon. So, we'll see. It's about understanding the blast radius and understanding your use case.Betty: Yep. A hundred percent.Corey: So, you've spent a fair bit of time doing interesting things in your career. This is your second outing at VMware, and in the interim, you were at solo.io for a bit, and before that you were in a marketing leadership role at Docker. Let's dive in, if you will. Given that you are no longer working at Docker, they recently made an announcement about a pricing model change, whereas it is free to use Docker Desktop for anyone's personal projects, and for small companies.But if you're a large company, which they define is ten million in revenue a year or 250 employees—those two things don't go alike, but okay—then you have to wind up having a paid plan. And I will say it's a novel approach, but I'm curious to hear what you have to say about it.Betty: Well, I'd say that I saw that there was a lot of flutter about that news, and it's kind of a, it doesn't matter where you draw the line in the sand for the tier, there's always going to be some pushback on it. So, you have to draw a line somewhere. I haven't kept up with the details around the pricing models that they've implemented since I left Docker a few years ago, but monetization is a really important part for a startup. You do have to make money because there are people that you have to pay, and eventually, you want to get off of raising money from VCs all the time. Docker Desktop has been something that has been a real gem from a local developer experience, right, giving the—so that has been well-received by the community.I think there was an enterprise application for it, but when I saw that, I was like, yeah, okay, cool. They need to do something with that. And then it's always hard to see the blowback. I think sometimes with the years that we've had with Docker, it's kind of like no matter what they do, the Twitterverse and Hacker News is going to just give them a hard time. I mean, that is my honest opinion on that. If they didn't do it, and then, say, they didn't make the kind of revenue they needed, people would—that would become another Twitter thread and Hacker News blow up, and if they do it, you'll still have that same reaction.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: It seems to be that Docker has been trying to figure out how to monetize for a very long time because let's be clear here; I think it is difficult to overstate just how impactful and transformative Docker was to the industry. I gave a talk “Heresy in the Church of Docker” that listed a bunch of things that didn't get solved with Docker, and I expected to be torn to pieces for it, and instead I was invited to give it at ContainerCon one year. And in time, a lot of those things stopped being issues because the industry found answers to it. Now, unfortunately, some of those answers look like Kubernetes, but that's neither here nor there. But now it's, okay, so giving everything that you do that is core and central away for free is absolutely part of what drove the adoption that it saw, but goodwill from developers is not the sort of thing that generally tends to lead to interesting revenue streams.So, they had to do something. And they've tried a few different things that haven't seemed to really pan out. Then they spun off that pesky part of their business that made money selling support contracts, over to Mirantis, which was apparently looking for something now that OpenStack was no longer going to be a thing, and Kubernetes is okay, “Well, we'll take Docker enterprise stuff.” Great. What do they do, as far as turning this into a revenue model?There's a lot of the, I guess, noise that I tend to ignore when it comes to things like this because angry people on Twitter, or on Hacker News, or other terrible cesspools on the internet, are not where this is going to be decided. What I'm interested in is what the actual large companies are going to say about it. My problem with looking at it from the outside is that it feels as if there's significant ambiguity across the board. And if there's one thing that I know about large company procurement departments, it's that they do not like ambiguity. This change takes effect in three or four months, which is underwear-outside-the-pants-superhero-style speed for a lot of those companies, and suddenly, for a lot of developers, they're so far removed from the procurement side of the house that they are never going to have a hope of getting that approved on a career-wide timespan.And suddenly, for a lot of those companies, installing and running Docker Desktop just became a fireable offense because from the company's perspective, the sheer liability side of it, if they were getting subject to audit, is going to be a problem. I don't believe that Docker is going to start pulling Oracle-like audit tactics, but no procurement or risk management group in the world is going to take that on faith. So, the problem is not that it's expensive because that can be worked around; it's not that there's anything inherently wrong with their costing model. The problem is the ambiguity of people who just don't know, “Does this apply to me or doesn't this apply to me?” And that is the thing that is the difficult, painful part.And now, as a result, the [unintelligible 00:17:28] groups and their champions of Docker Desktop are having to spend a lot more time, energy, and thought on this than it would simply be for cutting a check because now it's a risk org-wide, and how do we audit to figure out who's installed this previously free open-source thing? Now what?Betty: Yeah, I'll agree with you on that because once you start making it into corporate-issued software that you have to install on the desktop, that gets a lot harder. And how do you know who's downloaded it? Like my own experience, right? I have a locked-down laptop; I can't just install whatever I want. We have a software portal, which lets me download the approved things.So, it's that same kind of model. I'd be curious because once you start looking at from a large enterprise perspective, your developers are working on IP, so you don't want that on something that they've downloaded using their personal account because now it sits—that code is sitting with their personal account that's using this tool that's super productive for them, and that transition to then go to an enterprise, large enterprise and going through a procurement cycle, getting a master services agreement, that's no small feat. That's a whole motion that is different than someone swiping a credit card or just downloading something and logging in. It's similar to what you see sometimes with the—how many people have signed up for and paid 99 bucks for Dropbox, and then now all of a sudden, it's like, “Wow, we have all of megacorp [laugh] signed up, and then now someone has to sell them a plan to actually manage it and make sure it's not just sitting on all these personal drives.”Corey: Well, that's what AWS's original sales motion looked a lot like they would come in and talk to the CTO or whatnot at giant companies. And the CTO would say, “Great, why should we pick AWS for our cloud needs?” And the answer is, “Oh, I'm sorry. You have 87 distinct accounts within your organization that we've [unintelligible 00:19:12] up for you. We're just trying to offer you some management answers and unify the billing and this, and probably give you a discount as well because there is price breaks available at certain sizing.” It was a different conversation. It's like, “I'm not here to sell you anything. We're already there. We're just trying to formalize the relationship.” And that is a challenge.Again, I'm not trying to cast aspersions on procurement groups. I mean, I do sell enterprise consulting here at The Duckbill Group; we deal with an awful lot of procurement groups who have processes and procedures that don't often align to the way that we do things as a ten-person, fully remote company. We do not have commercial vehicle insurance, for example, because we do not have a commercial vehicle and that is a prerequisite to getting the insurance, for one. We're unlikely to buy one to wind up satisfying some contractual requirements, so we have to go back and forth and get things like that removed. And that is the nature of the beast.And we can say yes, we can say no on a lot of those questionnaires, but, “It depends,” or, “I don't know,” is the sort of thing that's going to cause giant red flags and derail everything. But that is exactly what Docker is doing. Now, it's the well, we have a sort of sloppy, weird set of habits with some of our engineers around the bring your own device to work thing. So, that's the enterprise thing. Let me be very clear, here at The Duckbill Group, we have a policy of issuing people company machines, we manage them very lightly just to make sure the drives are encrypted, so they—and that the screensaver comes out with a password, so if someone loses a laptop, it's just, “Replace the hardware,” not, “We have a data breach.”Let's be clear here; we are responsible about these things. But beyond that, it's oh, you want to have some personal thing installed on your machine or do some work on that stuff? Fine. By all means. It's a situation of we have no policy against it; we understand this is how work happens, and we trust people to effectively be grownups.There are some things I would strongly suggest that any employee—ours or anyone else—not cross the streams on for obvious IP ownership rights and the rest, we have those conversations with our team for a reason. It's, understand the nuances of what you're doing, and we're always willing to throw hardware at people to solve these problems. Not every company is like that. And ten million in revenue is not necessarily a very large company. I was doing the math out for ten million in revenue or 250 employees; assuming that there's no outside investment—which with VC is always a weird thing—it's possible—barely—to have a $10 million in revenue company that has 250 employees, but if they're full time they are damn close to a $15 an hour minimum wage. So, who does it apply to? More people than you might believe.Betty: Yeah, I'm really curious to how they're going to like—like you say, if it takes place in three or four months, roll that out, and how would you actually track it and true that up for people? So.Corey: Yeah. And there are tools and processes to do this, but it's also not in anyone's roadmap because people are not sitting here on their annual planning periods—which is always aspirational—but no one's planning for, “Oh, yeah, Q3, one of our software suppliers is going to throw a real procurement wrench at us that we have to devote time, energy, resources, and budget to figure out.” And then you have a problem. And by resources, I do mean resources of basically assigning work and tooling and whatnot and energy, not people. People are humans, they are not resources; I will die on that hill.Betty: Well, you know, actually resource-wise, the thing that's interesting is when you say supplier, if it's something that people have been able to download for free so far, it's not considered a supplier. So, it's—now they're going to go from just a thing I can use and maybe you've let your developers use to now it has to be something that goes through the official internal vetting as being a supplier. So, that's just—it's a whole different ball game entirely.Corey: My last job before I started this place, was a highly regulated financial institution, and even grabbing things were available for free, “Well, hang on a minute because what license is it using and how is it going to potentially be incorporated?” And this stuff makes sense, and it's important. Now, admittedly, I have the advantage of a number of my engineering peers in that I've been married to a corporate attorney for 11 years and have insight into that side of the world, which to be clear, is all about risk mitigation which is helpful. It is a nuanced and difficult field to—as are most things once you get into them—and it's just the uncertainty that befuddles me a bit. I wish them well with it, truly I do. I think the world is better with an independent Docker in it, but I question whether this is going to find success. That said, it doesn't matter what I think; what matters is what customers say and do, and I'm really looking forward to seeing how it plays out.Betty: A hundred percent; same here. As someone who spent a good chunk of my life there, their mark on the industry is not to be ignored, like you said, with what happened with containers. But I do wish them well. There's lot of good people over there, it's some really cool tech, and I want to see a future for them.Corey: One last topic I want to get into before we wind up wrapping this episode is that you are someone who was nominated to come on the show by a couple of folks, which is always great. I'm always looking for recommendations on this. But what's odd is that you are—if we look at it and dig a little bit beneath the titles and whatnot, you even self-describe as your history is marketing leadership positions. It is uncommon for engineering-types to recommend that I talk to marketing folks.s personally I think that is a mistake; I consider myself more of a marketer than not in some respects, but it is uncommon, which means I have to ask you, what is your philosophy of marketing because it very clearly is differentiated in the public eye.Betty: I'm flattered. I will say that—and this goes to how I hire people and how I coach teams—it's you have to be super curious because there's a ton of bad marketing out there, where it's just kind of like, “Hey, we do these five things and we always do these five things: blah, blah, blah, blah, blah.” But I think it's really being curious about what is the thing that you're marketing? There are people who are just focused on the function of marketing and not the thing. Because you're doing your marketing job in the service of a thing, this new widget, this new whatever, and you got to be super curious about it.And I'll tell you that, for me, it's really hard for me to market something if I'm not excited about it. I have to personally be super excited about the tech or something happening in the industry, and it's, kind of like, an all-in thing for me. And so in that sense, I do spend a ton of time with engineers and end-users, and I really try to understand what's going on. I want to understand how the thing works, and I always ask them, “Well”—so I'll ask the engineers, like, “So… okay, this sounds really cool. You just described this new feature and you're super excited about it because you wrote it, but how is your end-user, the person you're building this for, how did they do this before? Help me understand. How did they do this before and why is this better?”Just really dig into it because for me, I want to understand it deeply before I talk about it. I think the thing is, it shows a tremendous amount of respect for the builder, and then to try to really be empathetic, to understand what they're doing and then partner with them—I mean, this sounds so business-y the way I'm talking about this—but really be a partner with them and just help them make their thing really successful. I'm like the other end; you're going to build this great thing and now I'm going to make it sound like it's the best thing that's ever happened. But to do that, I really need to deeply understand what it is, and I have to care about it, too. I have to care about it in the way that you care about it.Corey: I cannot effectively market or sell something that I don't believe in, personally. I also, to be clear because you are a marketing professional—or at least far more of one than I ever was—I do not view what I do is marketing; I view it as spectacle. And it's about telling stories to people, it's about learning what the market thinks about it, and that informs product design in many respects. It's about understanding the product itself. It's about being able to use the product.And if people are listening to this and think, “Wait a minute, that sounds more like DevRel.” I have news for you. DevRel is marketing, they're just scared to tell you that. And I know people are going to disagree with me on that. You're wrong. But that's okay; reasonable people can disagree.And that's how I see it is that, okay, I'll talk to people building the service, I'll talk to people using the service, but then I'm going to build something with the service myself because until then, it's all a game of who sounds the most convincing in the stories that they tell. But okay, you can tell an amazing story about something, but if it falls over when I tried to use it, well, I'm sorry, you're not being accurate in your descriptions of it.Betty: A hundred percent. I hate to say, like, you're storytellers, but that's a big part of it, but it's kind of like you want to tell the story, so you do something to that people believe a certain thing. But that's part of a curated experience because you want them to try this thing in a certain way. Because you've designed it for something. “I built a spoon. I want you to use that to eat your soup because you can't eat soup with a fork.”So, then you'll have this amazing soup-eating experience, but if I build you a spoon and then not give you any directions and you start throwing it at cars, you're going to be like, “This thing sucks.” So, I kind of think of it in that way. To your point of it has to actually work, it's like, but they also need to know, “What am I supposed to use it for?”Corey: The problem I've always had on some visceral level with formal marketing departments for companies is that they can say that a product that they sell is good, they can say that the product is great, or they can choose to say nothing at all about that product, but when there's a product in the market that is clearly a turd, a marketing department is never going to be able to say that, which I think erodes its authenticity in many respects. I understand the constraints behind, that truly I do, but it's the one superpower I think that I bring to the table where even when I do sponsorship stuff it's, you can buy my attention but not my opinion. Because the authenticity of me being trusted to call them like I see them, for lack of a better term, to my mind at least outweighs any short-term benefit from saying good things about a product that doesn't deserve them. Now, I've been wrong about things, sure. I have also been misinformed in both directions, thinking something is great when it's not, or terrible when it isn't or not understanding the use case, and I am thrilled to engage in those debates. “But this is really expensive when you run for this use case,” and the answer can be, “Well, it's not designed for that use case.” But the answer should not be, “No it's not.” I promise you, expensive is in the eye of the customer not the person building the thing.Betty: Yes. This goes back to I have to believe in the thing. And I do agree it's, like not [sigh]—it's not a panacea. You're not going to make Product A and it's going to solve everything. But being super clear and focused on what it is good for, and then please just try it in this way because that's what we built it for.Corey: I want to thank you for taking the time to have a what for some people is no doubt going to be perceived as a surprisingly civil conversation about things that I have loud, heated opinions about. If people want to learn more, where can they find you?Betty: Well, they can follow me on Twitter. But um, I'd say go to vmware.com/cloud for our work thing.Corey: Exactly. VM where? That's right. VM there. And we will, of course, put links to that in the [show notes 00:30:07].Betty: [laugh].Corey: Thank you so much for taking the time to speak with me. I appreciate it.Betty: Thanks, Corey.Corey: Betty Junod, Senior Director of Multi-Cloud Solutions at VMware. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a loud, ranting comment at the end. Then, if you work for a company that is larger than 250 people or $10 million in revenue, please also Venmo me $5.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

About EdEd Boyajian, President and CEO of EDB, drives the development and execution of EDB's strategic vision and growth strategy in the database industry, steering the company through 47 consecutive quarters of recurring revenue growth. He also led EDB's acquisition of 2ndQuadrant, a deal that brought together the world's top PostgreSQL experts and positioned EDB as the largest dedicated provider of PostgreSQL products and solutions worldwide. A 15+ year veteran of the open source software movement, Ed is a seasoned enterprise software executive who emphasizes that EDB must be a technology-first business in order to lead the open source data management ecosystem. Ed joined EDB in 2008 after serving at Red Hat, where he rose to Vice President and General Manager of North America. While there, he played a central leadership role in the development of the modern business model for bringing open source to enterprises.Links:EDB: https://enterprisedb.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate: is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards, while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other, which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at Honeycomb.io/screaminginthecloud. Observability, it's more than just hipster monitoring. Corey: This episode is sponsored in part by our friends at Jellyfish. So, you're sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That's why they created the Jellyfish Engineering Management Platform, but don't you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you're doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part. Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's promoted episode is a treasure and a delight. Longtime listeners of this show know that it's not really a database—unless of course, it's Route 53—and of course, I don't solve pronunciation problems with answers that make absolutely everyone hate me. Longtime listeners of the show know that if there's one thing I adore when it comes to databases—you know, other than Route 53—it is solving pronunciation holy wars in such a way that absolutely everyone is furious with me as a result, and today is no exception. My guest is Ed Boyajian, the CEO of EDB, a company that effectively is the driving force behind the Postgres-squeal database. Ed, thank you for joining me.Ed: Hey, Corey.Corey: So, I know that other people pronounce it ‘post-gree,' ‘Postgresql,' ‘Postgres-Q-L,' all kinds of other things. We know it's decidedly not ‘Postgres-squeal,' which is how I go for it. How do you pronounce it?Ed: We say ‘Postgres,' and this is one of the great branding challenges this fantastic open-source project has endured over many years.Corey: So, I want to start at the very beginning because when I say that you folks are the driving force behind Postgres—or Postgres-squeal—I mean it. I've encountered folks from EDB—formerly EnterpriseDB—in the wild in consulting engagements before, and it's great because whenever we found an intractable database problem, back at my hands-on keyboard engineering implementation days, very quickly after you folks got involved, it stopped being a problem, which is kind of the entire point. A lot of companies will get up there and say, “Oh, it's an open-source project,” with an asterisk next to it and 15 other things that follow from it, or, “Now, we're changing our license so the big companies can't compete with us.” Your company's not named after Postgres-squeal and you're also—when you say you have people working on it, we're not talking just one or two folks; your fingerprints are all over the codebase. How do you engage with an open-source project in that sense?Ed: First and foremost, Postgres itself is, as you know, an independent open-source project, a lot like Linux. And that means it's not controlled by a company. I think that's inherently one of Postgres's greatest strengths and assets. With that in mind, it means that a company like EDB—and this started when I came to the company; I came from Red Hat, so I've been in open-source for 20 years—when I came to the company back in 2008, it starts with a commitment and investment in bringing technology leaders in and around Postgres into a business like EDB, to help enterprises and customers. And that dynamic intersection between building the core database in the community and addressing customer needs in a business, at that intersection is where the magic happens. And we've been doing that since I joined EDB in 2008; it was really an explicit focus for the company.Corey: I'd like to explore a little bit, well first and foremost, this story of is there a future for running databases in cloud environments yourself? And I have my own angry, loud opinion on this that I'm sure we'll get to momentarily, but I want to start with yours. Who is writing their own databases in the Year of our Lord 2021, rather than just using whatever managed thing is their cloud provider of choice today is offering for them?Ed: Well, let me give you context, Corey, because I think it matters. We've been bringing enterprise Postgres solutions to companies now, since the inception of the company, which dates back to 2004, and over that trajectory, we've been helping companies as they've done really two things: migrate away, in particular from Oracle, and land on Postgres, and then write new apps. Probably the first ten of the last 13 years since I've been in the company, the focus was in traditional on-prem database transformations that companies were going through. In the last three years, we've really seen an acceleration of that intersection of their traditional deployments and their cloud deployments. Our customers now, who are represented mostly in the Fortune 500 and Global 2000, 40% of our customers report they're deploying EDB's Postgres in the cloud, not in a managed context, but in a traditional EC2 or GCP self-managed cloud deployment.Corey: And that aligns with what I've seen, a fair bit. Years ago, I wound up getting the AWS Cloud Practitioner Certification—did a whole blog post on it—not because it was opening any doors for me, but because it let me get into the certified lounge at re:Invent, and ideally charge a battery and have some mostly crappy coffee. The one question I got wrong was I was honest when I answered, “How long does it take to restore an RDS database from snapshot backup?” Rather than giving the by-the-book answer, which is way shorter than I found in practice a fair bit of the time. And that's the problem I always ran into is that when you're starting out and building something that needs a database, and it needs a relational database that runs in that model so all the no SQL options are not viable for whatever reason, great, RDS is great for getting you started, but there's only so much that you can tune and tweak before you start to run into issues were, for particular workloads as they scale-out, it's no longer a fit for a variety of reasons.And most of the large companies that I work with that are heavily relational-database-driven have either started off or migrated to the idea of, “Oh, we're going to run our own databases on top of EC2 instances,” for a variety of reasons that, again, the cloud providers will say, “Oh, that's not accurate, and they're doing the wrong thing.” But, you know, it takes a certain courage to tell a large-scale customer, “You're doing it wrong.” “Well, why is that?” “Because I have things to sell you,” is kind of a terrible answer. How do you see it? Let's not pick on RDS, necessarily, because all of the cloud providers offered managed database offerings. Where do those make sense and where do they fall down?Ed: Yeah, I think many of our customers who made their first step into cloud picked a single vendor to do it, and we often hear AWS is been that early, early—Corey: Yeah, a five-year head start makes a pretty compelling story.Ed: That's right. And let's remember what these vendors are mostly. They are mostly infrastructure companies, they build massive data centers and set those up, and they do that beautifully well. And they lean on software, but they're not software companies themselves. And I think the early implementation of many of our customers in cloud relied on what I'll call relatively lightweight software offerings from their cloud vendor, including database.They traded convenience, ease of use, an easy on-ramp, and they traded some capability in some depth for that. And it was a good trade, in fact. And for a large number of workloads it may still be a good trade. But our more sophisticated customers, enterprise customers who are running Postgres or databases at scale in their traditional environments have long depended on a very intimate relationship with their database technology vendor. And that relationship is the intersection of their evolving and emerging needs and the actual development of the database capabilities in support of that.And that's the heart of who we are at EDB and what we do with Postgres and the many people we have committed to doing that. And we don't see our customers changing that appetite. So, I think for those customers, they've emerged more aware of the need to have a primary relationship with a database vendor and still be in cloud. And so I think that's how this evolves to see two different kinds of services side-by-side, what they really want is a Database as a Service from the database vendor, which is what we just announced here at Microsoft Ignite event.Corey: So, talk to me a little bit more about that, where it's interesting in 2021 to see a company launching a managed service offering, especially in the database space, when there's been so much pushback in different ways against the large cloud providers—[cough] Amazon—who tend to effectively lose sleep at night over the haunting fear that someone who isn't them is making money, somehow. And they will take whatever is available to them and turn it into a managed service offering. That's always been the fear, so people play games with licenses and the rest. Well, they've been running Postgres offerings for a long time. It is an independent open-source project.I don't think you can wind up forcing a license change through that says everyone except big companies can run this themselves and don't do a managed service with it because that cat is very much out of the bag. How is it that you're taking something to market now and expecting that to fare competitively?Ed: So, I think there's a few things that our customers are clearly telling us they want, and I think this is the most important thing: they want control of their data. And if you step back, Corey, look at it historically, they made a huge trade to big proprietary database companies, companies like Oracle, and they made that trade actually for convenience. They traded data to that database vendor. And we all know the successes Oracle's had, and the sheer extraordinary expense of those technologies. So, it felt like a walled garden.And that's where EDB and Postgres entered to really change that equation. What's interesting is the re-platforming that happened and the transformation to cloud actually had the same, kind of, binding effect; we now moved all that data over to the public cloud vendors, arguably in an even stickier context, and now I think customers are realizing that's created a dimension of inflexibility. It's also created some—as you rightly pointed out—some deficiencies in technical depth, in database, and in software. So, our customers have sorted that out and are kind of coming back to middle. And what they're saying is, “Well, we want all the advantages of an open-source database like a Postgres, but we want control of the data.”And so what control looks like is more the ability to take one version of that software—in our case, we're worrying about Postgres—and deploy the same thing everywhere they go. And that opens the door up for EDB to be their partner as a traditional on-prem partner, in the cloud where they run our Postgres and they manage it themselves, and as their managed service, Postgres Database as a Service Provider, which is what we're doing.Corey: I've been something of a bear on the idea of, “I'm going to build a workload to run everywhere in every cloud provider,” which I get. I think that's generally foolish, and people chasing that, with remarkably few exceptions, are often going after the wrong thing. That said, I'm also a fan of having a path to strategic Exodus, where Google's Cloud Spanner is fascinating, DynamoDB is revelatory, Cosmos DB is a security nightmare, which is neither here nor there, but the idea that I can take a provider's offering that even if it solves a bunch of problems for me, well, if I ever need to move this somewhere else for any reason, I'm re-architecting, my data model and re-architecting the built-in assumptions around how the database acts and behaves, and that is a very heavy lift. We have proof of that from Amazon, who got up on stage and told a story about how much they hate Oracle, and they're migrating everything off of Oracle to Aurora, which they had to build in order to get off of Oracle, and it took them three years to migrate things. And Oracle loves telling that story, too.And it's, you realize you both sound terrible when you tell that story? It's, “This is a massive undertaking that even we struggle with, so you should probably not attempt it.” Well, what I hear from that is good God, don't wind up getting locked into a particular database that is only available from one source. So, if you're all-in on a cloud provider, which I'm a fan of, personally—I don't care which one but pick a cloud provider—having a database that is not only going to work in that environment is just a reasonable step as far as how I view things. Trading up that optionality has got to pay serious dividends, and in many database use cases, I've just don't see it.Ed: Yeah, I think you're bringing up a really important point. So, let's unpack it for a minute.Corey: Please.Ed: Because I think you brought up some really prominent specialty database technologies, and I'm not sure there's ever a way out of that intersection and commitment to a single vendor if you pick their specialty database. But underneath this is exactly one of the things that we've worried about here at EDB, which is to make Postgres a more capable, robust database in its entirety. A Postgres superpower is its ability to run a vast array of workloads. Guess what, it's not sexy. It's not sexy not to be that specialty database, but it's incredibly powerful in the hands of an enterprise who can do more.And that really creates an opportunity, so we're trying to make Postgres apply to a much broader set of workloads, from traditional systems of record, like your ERP systems; systems of analysis, where people are doing lightweight analytic workloads or reporting, you can think in the world of data warehouse; and then systems of engagement, where customers are interacting with a website and have a database on the backend. All areas Postgres has done incredibly well in and we have customer experience with. So, when you separate out that core capability and then you look at it on a broader scale like Postgres, you realize that customers who want to make Postgres strategic, by definition need to be able to deploy it wherever they want to deploy it, and not be gated or bound by one cloud vendor. And all the cloud vendors picked up Postgres offerings, and that's been great for Postgres and great for enterprises. But that corresponding lock-in is what people want to get away from, at this point.Corey: There's something to be said for acknowledging that there is a form of lock-in as far as technology selection goes. If you have a team of folks who are terrific at one database engine and suddenly you're switching over to an entirely different database, well, folks who spent their entire career working on one particular database that's still in widespread use are probably not super thrilled to stick around for that. Having something that can migrate from environment to environment is valuable and important. When you say you're launching this as a database as a service offering, how does that actually work? Is that going to be running in your own cloud environment somewhere and people just make queries across the wire through standard connections to the database like they would something locally? Are you running inside of their account or environment? Is it something else?Ed: So, this is a fully-managed database as a service, just like you'd get from any cloud vendor or DBAAS vendor that you've worked with in the past, just being managed and run by EDB. And with that, you get lot of the goodies that we bring, including our compatibility, and all our deep Postgres expertise, but I think one of the other important attributes is we're going to run that service in our clients' account, which gives them a level of isolation and a level of independence that we think is really important. And as different as that is, it's not heroic; it's exactly what our customers told us they wanted.Corey: There's something to be said for building the thing that your customers have said that they want and make sense for you to build as opposed to, “We're going to build this ridiculous thing and we're sure folks are going to love it.” It's nice to see that shaping up in the proper order. And I've fallen victim to that myself; I think most technologists have to some extent. How big is EDB these days?Ed: So, we have over 650 employees. Now, around the world, we have 6000 customers. And of the 650 employees, about 300 of those are focused on Postgres. A subset of that are 30-odd core team members in the Postgres community, committers in the Postgres community, major contributors, and contributors in the Postgres community. So, we have a density of technical depth that is really unparalleled in Postgres.Corey: You're not, for lack of a better term, pulling an Amazon, insofar as you're, “Well, we have three people working on open-source projects, so we're going to go ahead and claim we're an open-source company,” in other words. Conversely, you're also not going down the path of this is a project that you folks have launched, and it claims to be open-source because we love it when people volunteer for for-profit entities, but we exercise total control over the project. You have a lot of contributors, but you're also still a minority, I think the largest minority, but still a minority of people contributing to Postgres.Ed: That's right. And, look, we're all-in on Postgres, and it's been that way since I got here. As I mentioned earlier, I came from Red Hat where I was—I was at Red Hat for a little over six years, so I've been an open-source now for 20 years. So, my orientation is towards really powerful, independent open-source projects. And I think we'll see Postgres really be the most transformative open-source technology since Linux.I think we'll see that as we look forward. And you're right, though, I think what's powerful about Postgres is it's an independent project, which means it's supported by thousands of contributors who aren't tied to single companies, around the world. And it just makes the software—we develop innovation faster, and I think it makes the software better. Now, EDB plays a big part in there. Roughly, a little less than a third of the last res—actually, the 13 release—were contributions that came from contributors who came from EDB.So, that's not a majority, and that's healthy. But it's a big part of what helps move Postgres along and there aren't—you know, the next set of companies are much, much—next set of combined contributors add up to quite small numbers. But the cloud vendors are virtually non-existent in that contribution.Corey: This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals. Having the highest quality content in tech and cloud skills, and building a good community the is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. Its both useful for individuals and large enterprises, but here's what makes it new. I don't use that term lightly. Cloud Academy invites you to showcase just how good your AWS skills are. For the next four weeks you'll have a chance to prove yourself. Compete in four unique lab challenges, where they'll be awarding more than $2000 in cash and prizes. I'm not kidding, first place is a thousand bucks. Pre-register for the first challenge now, one that I picked out myself on Amazon SNS image resizing, by visiting cloudacademy.com/corey. C-O-R-E-Y. That's cloudacademy.com/corey. We're gonna have some fun with this one!Corey: Something else that does strike me as, I guess, strange, just because I've seen so many companies try to navigate this in different ways with varying levels of success. I always encountered EDB—even back when it was EnterpriseDB, which was, given their love of acronyms, I'm still somewhat partial to. I get it; branding, it's a thing—but the folks that I engaged with were always there in a consulting service's capacity, and they were great at this. Is EDB a services company or a product company?Ed: Yeah, we are unashamedly a product technology company. Our business is over 90% of our revenue is annually recurring subscription revenue that comes from technical products, database server, mostly, but then various adjacent capabilities in replication and other areas that we add around the database server itself. So no, we're a database technology company selling a subscription. Now, we help our customers, so we do have a really talented team of consultants who help our customers with their business strategy for Postgres, but also with migrations and all the things they need to do to get Postgres up and running.Corey: And the screaming, “Help, help, help, fix it, fix it, fix it now,” emergencies as well.Ed: I think we have the best Postgres support operation in the world. It is a global 24/7 organization, and I think a lot of what you likely experienced, Corey, came out of our support organization. So, our support guys, these guys aren't just handling lightweight issues. I mean, they wade into the gnarly questions and challenges that customers face. But that's a support business for us. So, that's part and parcel. You get that, it's included with the subscription.Corey: I would not be remembering this for 11 years later, if it hadn't been an absolutely stellar experience—or a horrible experience, for that matter; one or the other. You remember the superlatives, not the middle of the road ones—and if it hadn't been important. And it was. It also noteworthy; with many vendors that are product-focused, their services may have an asterisk next to it because it's either a, “Buy our product and then we'll support it,” or it's, “Ohh, we're going to sell you a whole thing just to get us on the phone.” And as I recall, there wasn't a single aspect of upsell involved in this.It was, “Let's get you back up and running and solve the problem.” Sure, later in time, there were other conversations, as all good businesses will have, but there was no point during those crisis moments where it felt like, “Oh, if you had gone ahead and bought this thing that we sell, this wouldn't happen,” or, “You need to buy this or we won't help you.” I guess that's why I've contextualized you folks as a services company, first and foremost.Ed: Well, I'm glad you have that [laugh] experience because that's our goal. And I think—look, this is an interesting point where customers want us to bring that capability to their managed DBAAS world. Step back again, go back to what I said about the big cloud vendors; they are, at their core, infrastructure companies. I mean, they're really good at that. They're not particularly well-positioned to take your Postgres call, and I don't think they want that call.We're the other guys; we want to help you run your Postgres, at scale, on-prem, in the cloud, fully managed in the cloud, by EDB, and solve those problems at the same time. And I think that's missing in the market today. And we can step back and look at this overall cloud evolution, and I think some might think, “Gee, we're into the mature phase of cloud adoption.” I would tell you, since the Red Sox have done well this year, I think in a nine-inning baseball game—for those of your listeners who follow American baseball—we're in, like, the top of the second inning, maybe. Maybe the bottom of the second inning. So, we've been able to listen and learn from the experiences our customers have had. I think that's an incredible advantage as we now firmly plant ourselves in the cloud DBAAS market alongside our robust Postgres capabilities that you experienced.Corey: The world isn't generating less data, and it's important that we're able to access that in a bunch of different ways. And the last time I really was playing with relational databases, you can view my understanding of it as Excel with a weirder interface, and you're mostly there. One thing that really struck me since the last time I went deep into database-land over in the Postgres-squeal world has been just the sheer variety of native data types that it winds up supporting. The idea of, “Here's some JSON. Take this and store it that way,” or it's GIS data that it can represent, or the idea of having data types that are beyond just string or var or whatever other somewhat limited boolean values or whatnot. Without having just that traditional list, which is of course all there as well. It also seems to have extensively improved its coverage that just can only hint to my small mind about these things and what sort of use cases people are really putting these things into.Ed: Yeah, I think this is one of Postgres' superpowers. And it started with Mike Stonebraker's original development of Postgres as an object-relational database. Mike is an adviser to EDB, which has been incredibly helpful as we've continued to evolve our thinking about what's possible in Postgres. But I think because of that core technology, or that core—because of that core technical capability within Postgres, we have been able to build a whole host of data types. And so now you see Postgres being used not just as the context of a traditional relational database, but we see it used as a time-series database. You pointed out a geospatial database, more and more is a document-oriented database with JSON and JSONB.These are all the things that make Postgres have much more universal appeal, universal appeal to developers—which is worth talking about in the recent StackOverflow developer survey, but we can come back to that—and I think universal applicability for new applications. This is what's bringing Postgres forward faster, unlike many of the specialty database companies that you mentioned earlier.Corey: Now, this is something that you can use for your traditional CRUD app, the my first hello world app that returns something from a database, yeah, that stuff works. But it also, for example, has [cyter 00:25:09] data types, where you can say, give me the results where the IP range contains this address, and it'll do that. Before that, you're trying to solve a whole bunch of very messy things in application logic that's generally awful. The database now does that for you automatically, and there's something—well, it would if I were smart and used it instead of storing it as strings because I make terrible life choices, but for sensible people, it solves a lot of those problems super well. And it's taken the idea of where logic should live in application versus database, and sort of turn a lot of those assumptions I was starting my career with on their head.Ed: Yeah, I think if you look now at the appeal of Postgres to developers, which we've paid a lot of attention to—one of our stated strategies at EDB is to make Postgres easier. That's been true for many years, so a drive for engineering and development here has been that call to action. And if you measure that, over time, we've been contributing—not alone, but contributing to making Postgres more approachable, easier to use, easier to engage with. Some of those things we do just through edb.com, and the way we handle EDB docs is a great example of that, and our developer advocacy and outreach into adjacent communities that care about Postgres. But here's where that's landed us. If you looked at the last Stack Overflow developer survey—the 2021 Stack Overflow developer survey, which I love because I think it's very independent-oriented—and they surveyed, I think this past year was 80,000 developers.Corey: Oh yeah, if Stack Overflow is captured by any particular constituency, it's got to be ‘Big Copy and Paste' that is really behind them. But yeah, other than the cabal of keyboard manufacturers for those copy-and-paste stories, yeah, they're fairly objective when it comes to stuff like this.Ed: And if you look at that survey, Corey, if you just took and summed it because it's helpful to sum it, most used, most loved, and most wanted database: Postgres wins. And I find it fascinating that if you—having been here, in this company for 13 years and watch the evolution from—you know, 13 years ago, Postgres needed help, both in terms of its awareness in the market and some technical capabilities it just lacked, we've come so far. For that to be the new standard for developers, I think, is a remarkable achievement. And I think it's a representation of why Postgres is doing so well in the market that we've long served, in the cloud market that we are now serving, and I think it speaks to what's ahead as a transformational database for the future.Corey: There really is something to be said for a technology as—please don't take this term the wrong way—old. As a relational database, Postgres has been around for a very long time, but it's also not your grandparents' Postgres. It is continuing to evolve. It continues to be there in a bunch of really interesting ways for developers in a variety of different capacities, and it's not the sort of thing that you're only using in, “Legacy environments,” quote-unquote. Instead, it's something that you'll see all over the place. It is rare that I see an environment that doesn't have Postgres in it somewhere these days.Ed: Yeah, I think quite the contrary to the old-school database, which I love that; I love that shade because when you step away from it, you realize, the Postgres community represents the very best of what's possible with open-source. And that's why Postgres continues to accelerate and move forward at the rate that it does. And obviously, we're proud to be a contributor to that, so we don't just watch that outcome happen; we're actually part of creating it. But I also think that when you see all that Postgres has become and where it's going, you really start to understand why the market is adopting open-source.Corey: It's one of those areas where even if some company comes out with something that is amazing and transformatively better, and you should jump into it with both feet and never look back, yeah, it turns out that it takes a long time to move databases, even when they're terrible. And you can lobby an awful lot of accusations at Postgres—or Postgres-squeal—but you can't call it terrible. It's used in enough interesting applications by enough large-scale companies out there—and small as well—that it's very hard to find a reason not to explore it. It's my default relational database when Route 53 loses steam. It just makes sense in a bunch of ways that other things really didn't for me before.Ed: Yeah, and I think we'll continue to see that. And we're just going to keep making Postgres better. And it gets better because of that intersection, as I mentioned, that intimate intersection between enterprise users, and the project, and the community, and the bridge that a company like EDB provides for that. That's why it'll get better faster; the breadth of use of Postgres will keep it accelerating. And I think it's different than many of the specialty databases.Look, I've been in open-source now for 20 years and it's intriguing to me how many new specialty open-source databases have come to market. We tend to forget the amount of roadkill we've had over the course of the past ten years of some of those open-source projects and companies. We certainly are tuned into some of the more prolific ones, even today. And I think again, here again, this is where Postgres shines, and where I think Postgres is a better call for a long-term. Just like Linux was.Corey: I want to thank you for taking so much time out of your day to talk to me about databases, which given my proclivities, is probably like pulling teeth for you. If people want to learn more, where can they find you?Ed: So, come to enterprisedb.com. You still get EnterpriseDB, Corey. Just come to enterprise—Corey: There we go. It's hidden in the URL, right in plain sight.Ed: Come to enterprisedb.com. You can learn all the things you need about the technology, and certainly more that we can do to help you.Corey: And we will, of course, put links to that in the [show notes 00:31:10]. Thank you once again for your time. I really do appreciate it.Ed: Thanks, Corey. My pleasure.Corey: Ed Boyajian, CEO of EDB. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a long angry comment because you are one of the two Amazonian developers working on open-source databases.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Show notes:Links:Garrett DimonMinitest HeatHeat Map Reporter for MinitestReviewStarting & SustainingSifter AppAutomated transcript (only about 70% accurate)Ben  Welcome to FounderQuest, this has been Today, I'm interviewing Garrett Diamond Star and josh are taking the day off and I get a chat with Garrett, who's a longtime friend of mine and fantastic entrepreneur and all around great person in the world, so I'm excited to have you here. Gary, Thanks, Garrett  thanks for having me. Ben  It's always fun catching up with you. I think the last time we chatted was business of software a few years ago, wasn't it? Garrett  Yeah, not frequently enough, Ben  so that was, yeah, definitely not frequent enough. One thing I most remember about that business of software was that was when the hurricane was coming through and so I was standing out there in boston with all the wind and the Garrett  right, having grown Ben  up in the south, that was kind of ironic that I was there in the northeast and getting a hurricane. Mhm. So have you been Garrett  three, so just uh probably about the same as everybody else man, you know, just kinda one day at a time and keeping it going um and yeah, I just kind of dabbling and exploring and for once the last year just kind of let myself be undirected and just kind of followed what was interesting and pulled on threads and uh a little unnerving but also kind of nice and refreshing, I don't know, you know, so kind of bouncing around like a ping pong ball. Ben  Well, that's, that sounds pretty cool. Well, let's talk about that in a minute. I want to catch people up so I'm sure most people know you, but just for those who don't. So Garrett again, it's been a long time entrepreneur I think. I think I first bumped into you with doing sifter, your, your, your app from a few years ago, you built that from scratch solo entrepreneur and then you sold that. Then you're, you're at post uh, postmark for awhile for that. Right. Garrett  Well, wild bit at large, but primarily on postmark. Yeah. Ben  Okay. Right. Right. So you're a while, but for a while and then I guess it was a couple of years ago now that you've left wild. Garrett  Yeah, it's been about . years, I guess. No. Okay. Ben  Yeah. And so I guess also during that time you kind of did the starting and sustaining books slash video series slash thing. That was cool. Garrett  Yeah, I've been dabbling in all that, trying to share my battle wounds so that other people can maybe avoid them or less than them. Ben  Yeah, that's awesome. I remember, I remember buying that. It's good, good stuff. So also linked in the show notes. Maybe we'll get a sailor to uh, you spoke, you spoke at Microsoft a few times or at least once that I can remember Garrett  I can't even keep track now. Microsoft spoke once attended a couple of times. Yeah. Ben  And so now you're doing some, some interesting stuff. So I remember, remember when you left a wild bit, you were, you're really interested in getting started on helping amputees have a community and so you started adapted, right? So, we're gonna talk about that for a second, and then we can talk about, you know, how that plan kind of changed for you with the passage? Garrett  Um, I mean, so I'm a left below knee amputee. And when I was trying to make that decision, I couldn't find any information on what life is really like as an amputee, um, let alone specific information about, can I play basketball still, if so, how does that work? Or what other activities can I do? And there's just not a lot of detailed information, and with disability, even just within amputees, the range is incredible, like above me and bologna makes a complete difference in how you function and your body mechanics, and so I just couldn't find this information out there. And so that kind of planted the seed that obviously it's not out there and, you know, it's woefully under informed, which at first was kind of scary, it's like, oh, I guess nobody does any of this stuff Garrett  and for me, the whole, ironically, the whole point of amputating was so that I could get back to doing things because of my ankle fusion was horrible and all that, it's just hurt and was miserable and through the whole thing, I was blogging about it, and what would happen is people would email me because they'd go on google and search for amputation, ankle fusion, that kind of thing, and then they'd ask me like, I'm, because I was the only person that came up and I would get these emails, you know, it kind of varies and go ebbs and flows, you know, to a month, once a week, you know, so frequently enough. Um, and uh, one uh, young woman that reached out to me, she actually amputated and then just won a couple of gold medals in the paralympics and like, Garrett  it just blew my mind is like, how do you find the answers to this stuff? And uh, after being an amputee now about five years and trying stuff and just kind of figuring it out. Uh, my hope was originally, I was like, well, I'm a software developer, I'll build a platform so people can share that information, um, you know, and I figured I was really optimistic about that specifically, because, well I built sifter and rails has gotten way better and I learned a ton from sifters, it'll be way easier this time around, but I didn't really account for was now I've got a family and I'm  years older, uh and so it's been more challenging at the end of the day, I'm just tapped on software because I'm doing that all day and my brain is fried. Garrett  Um, but I've been doing videos kind of explaining this stuff to people about how legs work and the logistics of like how they change your body mechanics and um, how to do things like go to the beach and deal with sand in your foot and that kind of stuff. Uh, and I did that more is like an exploratory whimsical thing because that was the kind of content I hope people would create and put on the platform. So then you could filter and say, here's my disability, here's the activity I want to do. Give me all the information about that specific thing. Um, but I did it and it just kind of left it for a year, but it just kept going and then more people have been contacting me and so now what I'm doing is kind of Garrett  stepping back from the software side of it and I'm just gonna keep recording videos for the next short term, um, and having them produced and that kind of stuff and hopefully increasing the quality and the depth and then doing interviews with other amputees and really kind of getting into more stuff, um, and then eventually circling back to building a platform to help people find the right things that meet their needs and that kind of thing. Um, so, you know, it's, it's, it's been tough. I think the toughest thing is realizing that nonprofit side projects are the hardest thing to make time for, um because it's never going to offset my income or anything. And so like Garrett  now I've kind of been thinking, I guess I need to build a business again. So I've got more ironically more free time um, just because Sassen recurring revenue all that's so great that it would give me the flexibility to do that and to spend more time helping people and building um software and all that. So kind of just juggling things and figuring it out. And that's kind of where a lot of the exploration has come in. I haven't really prescribed where I'm taking things and uh um spending a lot of time dabbling and ruby and getting kind of deeper into it than I ever have previously. And uh exploring video and trying to help people with that stuff. So just kind of playing around and tinkering and trying to make ends meet at the same time and I'll figure it out, I guess Ben  that's cool. There's a whole lot to unpack in there. So let's, let's talk about some of that. So, Some of the, some of the themes, well, at first, I guess I should say I can totally relate to you with the whole, you know,  years later and now, there's. yeah, there's more demands on your time. There's less energy in the body and there's, you know, less energy in the brain probably is more importantly. Um, I've had that, that same thing I recently started picking up some side projects, you know, and like, yeah, they're just, you have fewer hours in the day that you really feel like being really into that kind of mode, you know, that your brain stuff and, Ben  and I've noticed that uh I can tell like when my blood sugar is getting low and now we're like, I've I've used up too many brain cells, I gotta go back and recharge, you Garrett  know? Uh Ben  So it's interesting that dynamics, like, I don't quite have the appetite that I used to have to just dive in and, and, you know, slog away at the keyboard for hours. And then Garrett  for me, it's also been awareness, like, I recognize it more now when I, when I was younger I would push through and be like, oh, grind and hustle and you know, and now I'm like, ok, I need to stop, this isn't, you know, if I don't stop, I'm going to be a complete mess tomorrow and not want to work and not be able to think. And so I catch it earlier and I just stopped and I hate it because I still, like, interested in whatever problem is in my head is still tugging on it and, you know, it's trying to and it's really hard to just turn it off and walk away. Um but I've gotten better at that a little, Ben  One of the things that I've noticed as, as I've gotten older in this tech world. So I guess I've been doing it  years or  years or so, is that, um, uh, so that that energy for doing all the things is not there? Like it used to be, but it seems like the deep thinking is more refined is more home. So like you said, like you're going to be, you know, you're just not going to have the energy, you're not going to be wasted the next day. And I think I've seen that too. And I think it's not just from like the energy of working, it's from the energy of thinking deeply about what's the right solution here, right? Ben  It's not so much like just powering through it. Okay, I'm gonna build this stuff and I'm gonna backtrack and I'm gonna redo and backtrack and redo now. It's like, oh, I'm gonna think about this and I'm going to get it right right? And then you apply that precision cut I guess. Garrett  And for me, the struggle is having the wisdom to recognize they should stop, but I can't turn off the excitement or the interest, right? And so I do still want to work on it. I just know better. And it's hard when those two don't align. Yeah, that's, that's been a struggle. Ben  Yeah, I've seen saying the same thing, but I think my living experience so far has been like the, the eventual outcome is better, even even when I have that, you know, I want to do more, but I don't know, I don't have the energy to more, But having that time to reflect more when I do sit down next time and have that  minutes an hour or whatever, like that time is much better spent coming up with the right solution rather than Garrett  just uh just the other day. I was and I mean, I think we've all had this happen a million times, but this just happened. I don't know, friday, I think banging my head on the desk for an hour and a half on this thing. That just makes no sense. There's a ruby thing like this doesn't make sense. What am I missing here? Like is there some really quirky ruby behavior I don't understand. Um And hour and a half and finally was like, I've got to give up, I've got to stop, this isn't getting anywhere. And it was only like , right? So I still was like, I had time in the day, I was like, I just got to stop The next morning. I sat down with in  minutes, Garrett  like solve cold, right? Like there's no, that was from the time I sat at my desk at the time, I solve the problem and it was just, you've got to step away and clear your head or you know, it just doesn't go well, Ben  yeah, yeah, I've had that same experience so many times and uh I think a lot of times you hear people say yeah just take a break, go for a walk whenever you're like yeah what everyone's gonna power through it but it actually does work Garrett  well for me. Walking doesn't cause then I'll just fix it on it too much and like I need to let go like my brain has to let it go. Um And so for me usually it's more getting a getting a night of sleep um is what kind of resets it for me at least from what I've found. But I've probably every three or four months. It's one of those where like This is going poorly and the next morning less than  minutes it's solved. Uh Ben  Yeah I have that too, like a good night. So definitely goes to reset. The one. The one problem I've had with that though is that then I will wake up at four a.m. I have the solution in my head, I'm like I got to go do it, Garrett  I do that too and for better or worse I don't even fight the sleep anymore, I just get up and go start working. Um And then if I need a nap later or something I just Ben  so be Garrett  it. Uh But like that's so much of that like We're so indoctrinated that like  is when people work. And that's been a really hard thing to let go of two and not feel that way every day and to basically, it's not about like working when you feel like it, but it's not like pushing back when the urge to get something done strikes, like go do it and then circle back, yeah, you know, and get some either for rest or whatever. Um you know, take a long lunch or whatever it is. Uh and that's uh I've found that to be helpful to just to try and not forced to work, but do it when it's fresh in my head and just go, Ben  yeah, yeah, I love having that flexibility as a, as an entrepreneur or business owner and being able to work when it's most effective. So You know, if it's  and then I take a break and maybe come back in a couple hours in the afternoon and then I'm done for the day, that's, it's cool. Right? So I wanted to hit on one other thing from, you're talking about there about with adaptable and you know, I love what you're saying about there's a, there's a software solution here, let me go build that, right? And then over time. Like uh maybe not. And I can totally relate to that because I feel the same way. It's like, oh if there's something missing in the world, there's, there's obviously assad's there that can satisfy that need, but Ben  but in reality like salad, you don't have to go all the way to says, right, you can uh, you can start with, you know, youtube videos or uh, maybe even just a reddit, right? Maybe maybe you're hanging out in the community and on offering back and building up that stuff that you want to see in the world. Garrett  Uh, so there's definitely still an element of that with what I want to do and uh, a lot of it is like, right now I'm focused on videos and more mechanics and uh, you know, here's things to think about if you want to get into mountain biking as an amputee or things to think about with snowboarding or, you know, whatever it is. Um, but there's this whole other facet or many facets really, um, of like limb care and recovery and you know, when you beat your leg up doing something active in a carbon fiber socket all day Garrett  and then you get home and it's destroyed, uh, you know, you got to take care of it. And so there's things like that and there's a financial aspect that like insurance only helped so much with prosthetics and they help with basic, like daily kind of day to day prosthetics, but they don't help if you need more advanced prosthetics, um, for certain activities. And so for that, you're either on your own or you need to find financial assistance and there's a ton of great organizations out there that help with that, but they're all non profits and their websites are less than stellar and less than informative. Um, Garrett  and in a lot of ways it's difficult to find the one that is right for you that will cover the type of equipment you need based on, you know, just your disability fall into the disabilities that they cover. Um, and so there's all these different requirements and details and it's difficult or you forget right, like life happens and some organization has an annual grant cycle and it's in october and then october blows by and you're like, oh crap, I totally forgot to apply for that grant and now you got to wait till next year. And so, you know, my thinking is that it's not just a tool to like educate people and help people find the information. They need something to proactively help reduce friction and remove the barriers that stop people with disabilities from being active. Garrett  Um, and that could be everything from pain to financial stuff to simply, you know, needing somebody to talk to who's done it. Um, and there's just, there's so many solutions and everybody, even within a category of disability is unique, even if they're not unique from the disability perspective, the activity they want to pursue might be more unique. Um, and so it's just really difficult to make it all work and to find answers and you kind of just gotta go try and you know, from experience the first couple of times I try new activity is miserable because I'm just figuring it out and that takes a lot of the fun out of it. And a lot of people like this isn't for me and you know, until you learn Garrett  kind of about that learning curve and how it exists and how it's a lot steeper than it is without a prosthetic or what have you. Um it's tough and it's easy to give up because it hurts and it's inconvenient and you know, there's just you're worried about your prosthetic, right? You've got this $, prosthetic that you need to survive day to day and you're like, oh I'm going to go paddleboarding, so what if it gets wet, can it get wet? I don't know, and there's just so many questions and so many easy reasons to give up or be intimidated and Garrett  you know, it doesn't need to be that way because more more importantly, like once you're in that situation is more important than ever to be active and to stay active and to not let it just lock you down on the couch or something. Um but it's not easy, you know, it's way harder than before and I don't think it needs to be, it doesn't need to be as hard as it is. So yeah, I'm hoping could help people get answers and you know, do their thing, whatever it is that moves them figuratively and literally Ben  yeah, yeah, that sounds like a tagline for the website Garrett  actually. Right. Ben  Right. Garrett  Yeah. Ben  Yeah. I I have uh so we have in our in our family some some experience with a kind of obscure medical issues like uh which is kind of similar to, you know, go into a prosthetic situation, right? Where all of a sudden you're into this community where you have to, you can get the speed really quickly on what does life look like now. And how do I do the things that I want to do and where do I go to find that information? And so often it seems that in our in our experience is that the only people who really know much of anything are the doctors that you're working with or the therapists or the nurses, right? And and they can connect with resources. But like if you just happen to have the wrong, you know, chemistry, Ben  you know, with with someone or you don't just happen to the right person, you can just feel pretty isolated. And uh so I thank you for having having resources for, for that is is so helpful because I've told my wife a number of times like you could write a book on on all the things that you've learned, you know, through this experience. And and then my my my brother's family there was a significant motorcycle accident that left someone with, you know, just a lot of parallelization from the waist down basically and his his, you know, going through all the things that he went through two surgeries and the rehab. And so to get back to a point where he could walk, you know, uh, which was, which was assisted so much by the great people that he had around him. Ben  But fortunately he had them right for those that don't, it's got to be a much, much harder rodeo Garrett  and it's just all over the board. Um, amputations really interesting is what most most frequently right into with people is there surgeon doesn't want them to amputate and is constantly trying to talk them out of it. But after you go through it, I saw my surgeon, I mean, my surgeon, I had to switch surgeons. Um, but he saw me twice after my amputation. He's never seen me with a prosthetic. He has no idea what I'm doing now. And so these people are asking their surgeons about amputation. The truth is the surgeons, unless they're actively helping. Um, you know, in other contexts and volunteering. Uh, they have no clue what life is like after amputation. They might read some stuff, Garrett  right. And you know, there's plenty of paralympians that are amazing. But then you wonder those people edge cases or you know, can anybody run and do that stuff again? Maybe not at that level. Um, and the, your surgeon just doesn't know. And so people are asking the surgeon because that's supposed to be the expert and then the surgeons giving them, I don't want to say bad information but incomplete information. And so it's tough for people because you can't get those answers, you know, and again, every disability so different how it affects people and how your doctor, what their background is in terms of how they understand like being active or you know, doing more than just day to day functioning. All right. Yeah. There's so many layers to it all. Mhm. Ben  So, one thing I wanted to go back to was talking about, you know, the time that you spend on that, obviously it's it's tough when you've got a family, you're the breadwinner. You know, you're trying to build a nonprofit thing. And at some point it sounds like you realize, you know what, I just gotta I gotta do some work. I got to bring the money in the door, right? I can't spend all my time focusing on this this nonprofit platform. So it sounds like you're doing that in your spare time and that you're you're paying the bills of freelancing doing a bunch of bunch of rail stuff. But as you've been doing that, you've actually built some tools that I want to talk about. So it sounds it sounds like Ben  you've been doing this work and this work has prompted you to build the review thing you've been working on. And also the heat map thing for many tests, let's talk about that a little bit. Garrett  Uh Yeah. So the nice thing, the one the only intentional thing I've done the last . years is to try and make sure that whatever I'm doing at all kind of syncs up somehow um and for the most part that was always leading back to ruby and or rails um and you know, so a lot of my client work is helping with legacy apps that are profitable now, but they built the app quickly and there's some, you know, legacy pain that needs to be fixed, re factoring that kind of thing. Um And then there was adaptable where I was starting with a Greenfield fresh modern rails app um and one of them was fun and the other one wasn't and I'll let you guess. Mhm. And so a lot of what I started thinking more about was like how does an app that Garrett  has all this legacy craft get from there to a point where it's not miserable to work on and you know, there's a lot of ways, there's a lot of paths, there's a lot of great books on re factoring um and a lot of that kind of stuff, uh what I started getting more interested in was how we've got all these great letters and static analysis tools for um security for syntax for just cleaning up code, right? And a lot of little auto correct and format stuff for you. Uh and the more I I dabbled with the tools previously but they were always so difficult to use because they're all command line um you know and they all have different syntax, different names for the same flags that do the same thing like Summer Garrett  auto, correct, some are right, some are, you know, and so like you gotta then remember the quirks, they're using the wrong flags with the wrong tools and it just gets tedious, right or like you know, you want to use a dozen tools, but if you run them all at once, like it's going to take  minutes to run through your whole project when really all you want is like just look at the files, I'm about to commit or uh you know look at the files, I just committed and let's do a pass it like with Robocop or whatever, clean them up and then I'll commit a separate one that's just pure clean up, you know, all these kind of things and but it was so tedious, I love these tools but I just wouldn't use them because there was too much friction. Garrett  Uh and so with adaptable and like when I start a Greenfield project, I was like I've got to use these tools from the beginning to make sure that never gets into a bad state because once that ship sails it's too much effort to go back and too much risk to like make those kind of wholesale changes and uh so it started with just that it's like how can I make it easier to use these tools and remove the friction so that they're enjoyable to use and kind of in the back of my mind was because like Guard does a lot of this, right, if you're running guard constantly. Uh But Guard also drove me nuts because it would my fans would spin up and make so much noise and I couldn't concentrate. Um Garrett  and so kind of and I still like guard, but my thinking was what if the tool could be so convenient that you didn't feel like you needed to use guard to watch files as you changed them and that you could do more than just have your automated test front, right? So like what if and I mean there's there's integrations for like Robocop and stuff, but like what if you change five files and you could just run a tool that will automatically run all of the relevant things you have against those files that you updated and potentially auto correct them if you want or um you know, this is all theory and it's it's come together and I'm using it on itself but it's not ready to like use in other projects yet. Um that's kind of the next step. Uh Garrett  But yeah and that's what I just I wanted that I want to be able to take it on a project that's raw and has a ton of craft and then every time I commit basically start cleaning up there and just make sure it doesn't regress, right it only gets better, you know and basically it makes it easier to or hopefully it will make it easier to just make constant steady improvement, right? It's not you run it and then it's like you know the tool just throws up its hands, it's like this code base is a mess, Ben  don't even Garrett  use this tool. Um Instead I want it to be you know what okay make some progress, let's start there and eventually, you know, over the course of a year, two years you're gonna touch so much of the code and eventually it's gonna get cleaner and it's gonna get better right? And it's not just formatting but like you've got things like brake man and things that are for scanning for security issues and all this stuff and there's so much bundler audit right and all these things to make sure that your dependencies and you know there's a lot of great tools out there like code, climate for reporting. But what drives me nuts is when I commit and then it gets to see I Garrett  and then the ci finds the mistake because the tool you don't run it locally like okay well now I've got to fix it and I gotta wait for ci again and like I want all these tools to be so frictionless to use, it never even makes it to see i like CS board because it never has anything to complain about because by the time it gets there it's already perfect. Um So yeah, so that's kind of the that's a reviewer um and it'll hopefully be more like the end of the year. Um And then I've also been obsessed with many tests lately because I used to use ours back and I just it never messed with me. It was too, I don't know, it's Garrett  the way I've always described, feels like it's the only thing in ruby that I feel like is simultaneously very ruby and very un ruby and it's just never worked with my head. Um And all the I'm very dependency averse from years of you know dependency breaks or has a security issue and the chain reaction of things that need to be updated and can't be updated because and so I'm very dependency averse. Um and uh so that's another reason I've gone with many tests because it's just there there's fewer dependencies, it's simpler. Um But many tests output even with all the formatting options out there just always, I felt like I was doing way more work than I should have to to figure out what failed what went wrong and how to fix it Garrett  and so what I've done is really over engineered to test reporter for many tests to uh when a test fails, it kind of catalogs what file was in the stack trace what line number in that file. Um and so what it's doing is in the background, it's kind of building up a heat map of everything that triggered a problem. And it's also differentiating between like failures and exceptions because if your test fails, okay, that's interesting. You want to start with the assertion, what was the assertion that failed? But if there is an exception, then the assertions kind of irrelevant. You want to go dig into the exception. But what if the exception came out of the test, Garrett  then you don't want to waste your time and source code just fix the test. Otherwise you're not. And so it differentiates between failures, a broken test and an exception. And it presents the output differently to kind of guide you in the right direction based on those. And if you've got anything that's failing or broken, it's not going to harass you about skipped tests or slow tests, right? It suppresses those until everything's fixed. And it's like, hey, by the way, you've got four tests here that you've skipped, you need to go right? Those, uh, and actually won't bother you about slow tests until all your skip tests are fixed, Right? Garrett  Uh, and so it kind of lets you focus on what's important at the time without reminding you of the fact that you've got a lot going on that is pending and problematic or whatever it is. Um, you know, so there's a lot of little things like that and like when you make that one change that breaks  things across your whole project, you're renaming a class or whatever it is. Uh And then it's just you will go from like a perfect test suite  failing tests like crap. Okay. Where do I even start? Uh And so the heat map will show you like look all of these problems come back to this one file, you know, whatever it is so you can get to the heart of the matter instead of having to like Garrett  visually scanned through  failures and try to find and recognize a pattern. Uh So it's kind of uh a proactive pattern matching reporter. Um you know with a few other tweaks to just help uh nudge and simplify kind of the output so that you can my hope be, you know, you see a test failure and you know exactly what you need to do to fix it before you even go back to your text editor because you've got enough context. Um And obviously that's not always possible, but more often than not and definitely more often than with just the generic reporter. Uh That's been the case and has been really helpful and saves me a ton of time fishing for what needs to be fixed and what what's worth fixing first and that kind of thing. So I have to think a lot less. Garrett  I just have to go fix it. Ah And so both of those combined are going to kind of I'm hoping work in a way that you know you type R. V. W. And it's just smart and it says here's all your problems. You're like oh my gosh, everything's perfect. But you could stand to improve your documentation here in this file, you're like okay I can do that real quick. Um You know so it kind of nudges you in the right direction without like wearing you out about how horrible your code is. Um Because when you're one of those tools just raw, that's basically what it feels like. It's like oh my gosh I'm horrible. I have no idea, I have no business writing code. Uh Garrett  And that's not a good feeling but if it's like hey you can fix this, here's how okay I can do that. Um You know there's a lot of really interesting ideas. There are like you know you ever run your test suite and it fails and you run it again and it passes. They're like oh crap what was the seed that it used when it failed? And uh so what reviewer does too in the background, it's recording a bunch of history. Um And so it will remember that last failed seed and so you can you be able to type our VW rerun and it would rerun just the failure and let you zero in on that and focus on fixing that. Um So there's a lot of little things like that that Garrett  I just want to make it easier. I mean there's bisect and some great tools out there. Um, but sometimes they're overkill and slow and they take you out of the zone and I want to make it easier to stay in the zone and get things done and get back on track. Ben  That sounds sounds really cool. Yeah, we um, remember having done some a few major rails version upgrades with the honey badger card base, you know, go from  to  or  or whatever it is. And like all of a sudden half your tests, you got thousands of tests and like thousands of them. It's the Garrett  most defeating feeling. You're just like, oh, okay, I quit for today. Ben  Yeah. And then, and then, you know, you dive through all those things like, okay, these all look the same. It's all the same. It's all the same and go and try this thing here and that thing there and oh, I made this one change and now half of those failing tests are now passing okay. Now, you know? So yeah, having the heat map I think is uh, it sounds like a great idea. And then of course, you know, you mentioned, uh, if it's an exception, you know exactly where to go, like it sounds like honey badger, right? You get the context that you need to know what to fix, right, yep. Yeah. Although I must say I'm, I'm an I respect fan Ben  have been for a long time and I've tried, you know, going back to many tests because I'll start your rails app like this, this new side project, I started a few a few months ago, like it's a new rails happen to me, you know, let me try any test again because that's the default and so I'll get in there for a bit. But then like one of the things I've come to realize is that I, what I love about our spec is despite how, you know, I can feel you about the dependency aversion, but at the same time our spec is kind of like a batteries included kind of thing. Like Ben  you've got the mocking right? Not the stubbing, you don't have to worry about what I do. I do, I do many test mock or do I do mocha, you know, like all that's kind of rails itself, right? It's kind of kind of its own duck and it has everything included. So you don't think about, you Garrett  know, and don't get me wrong, I don't dislike our spec, it just doesn't work with my head and like, I just get overwhelmed with how much it has. And so for me with many tests, like you're like, oh, which marked thing to use neither. Like if I feel like I need to mock something, I need to re factor it so it's more easy to test efficiently and directly. Um, because like marks, I mean that has all has its own issues, right? Like uh and so for me uh and and it was very much a mental thing. Like I just fully embraced accepted many tests limitations and now I use that as kind of a nudge to be like, all right, if this is really difficult to do, Garrett  then it's not that I need better testing tools. It's that I need my code to be organized in a way that lets me test this appropriately And efficiently without getting to set up  unrelated models so that it won't fall over. Uh And so that's kind of been more of a philosophical thing for me because previously when I drive many tests, that's exactly how to drive me nuts. I'm like, how the hell do I do any of this? Because my brain what little I did understand of our respect. I had learned to think that way about things. And so then I found myself doing all this like how do you mock in many tests and how do you, And it's like you don't, you know, use mocha or you know what have Ben  you. Garrett  Uh and so kind of accepting that and just saying, you know what, When it, when many test pushes back, I'm going to listen and I'll just re factor. Um and at first was a little painful. But now it actually has been really, really nice. Uh But I will say to a lot of that goes hand in hand with like I've been doing a lot of like deeper deeper reading on ruby and thus kind of understanding patterns, you know being able to see more patterns to re factor like oh this is why this is hard to test really. Just need to re factor using this pattern and take this approach instead or whatever. Um And so that's helped because otherwise I feel like I know I need to change this but I don't even know where to start. Um Garrett  So you know, that's definitely been a philosophical thing I had to accept. Ben  Yeah, that makes sense. So you mentioned code climate and I know, you know in the early days when kokonas started like it was basically a wrapper on top of flay and flaw right and eventually break man and stuff. Right? They assembled all these open source tools and put a nice ui on top of it, which is fine, you know, but you could just run off tools yourself, right? Um But review sounds pretty cool because you're basically giving that code climate kind of experience, but it's on your own right, in your own cli and you could I mean conceivably you could even use it like with left hook or something to do get pre commit kind of thing which might have its own problems but still it's an option. Garrett  It's definitely on the radar, there's a lot of get integration that I'm planning on. So you can do like our VW staged and it'll just look at the staged files or R. V. W untracked, it'll just looked at your file that you haven't staged, That kind of thing. Ben  Super handy. So do you do you see a path where review because there's some sort of commercial component to review or do you think it could always be pure, Garrett  there's, I've got a bunch of ideas that I think could um I mean the core one is just gonna be an open source jim. Um if I do follow any model um you know, it's probably going to be something more like sidekick where there's the core thing that is helpful and useful and free for eternity. Um and then there would be more advanced, either team functionality or kind of sharing of configuration files. Um There's a whole ton of tools that I've thought about building to to um things like if you have an existing app, it kind of auto detect and suggest, hey you might want to use these gems, these tools um obviously it's built in ruby but the idea is that it has to be ruby centric. It's really at the end of the day, it's just a wrapper for command line tools Garrett  that gives you some kind of either pass fail or score output. Um and so like if you've got  tools set up, like one reviewer, I've just gone overboard. Like I'll use everything because I want to kind of test it, you know, and dog food it um And so like if one fails it doesn't bother running the rest of them. And so the idea is if you can figure in the order of priority, like start with bundler audit right? Because if you've got a gym that's out of whack, then you need to fix that because that'll ripple And so it'll just stop there, so you have to wait  minutes for a whole suite to run on a huge project, it just fails immediately, insist fix this and then you fix that and then it runs Garrett  um and then two and this is all theoretical at this point because I haven't played with it, but I've got some, I'm really excited about the idea potentially. Um and I hate to make it ruby three only, but playing with tractors and some some threading and stuff so that you can have Robocop running in parallel with, you know, especially with multi core processors picking up and all this kind of stuff, I feel like there's a lot of potential Like what if you could run  tools in parallel and have the whole thing run in seconds instead of minutes and that could be really cool, There's other challenges there, but um you know that reporting obviously um like code climate, I feel like that's one of code climates really big things, Garrett  but for me the reporting is gonna be more an afterthought, I wanted to be a local thing that you can use friction free and then if people like it, which I hope they will, I mean I'm really excited about, I love using it to build itself, it's been wildly helpful. Um you know, then yeah, I'd start thinking about, you know, what other options are there for, how it could be better um and do even more cool stuff for teams or people who are just really serious about using it or you know, what have you? Ben  Mhm Yeah, I think, I mean I love, I love the sidekick model uh you know, give that great open source core that has great functionality and then build on top of that, you know, things that are useful to people who are going to use it more intensely and I think, I think the psychic definitely has that sweet spot, if it's it's an operations kind of thing where you're gonna be, you're gonna be running this forever in your production environment. So you want to pay that licensing fee, you know, every month, every year or whatever. And then there's also like the ASCII corp model, right? Where they have very, very good open source tools, you know, you can use Packer or Terror Form or whatever, Ben  you know, never paying them a dime but they also have great team collaboration tools if you want to move to their platform, you know, and coordinate your Terror Form running or you know, your console, you know, or your vault or whatever, right? They have a pro or enterprise offering for every one of those that can do additional stuff enhancing it, you know? So yeah, some great options there, Garrett  yeah, you know, I will say to a lot of my Garrett  thinking since selling sifter has been, I don't really want to run a sas app again, uh and I'm sure you can guess all the reasons uh at the end of the day, the simplest thing um and I mean I knew it when I was running sifter but I didn't fully appreciate it was the degree to which I let it change me to notifications and alerts of problems and a never ending fear that as soon as I went camping or hiking out of cell service was the day it was going to fall over in a bad way and uh like it wasn't this like huge thing, but it was just in this like ever present anxiety and after I didn't have that anymore, it was just such a like epiphany Garrett  that was like, I don't really want to go back there and if I build a SAS up, it needs to be something that can be designed in such a way that it's resilient and I know that, you know, if it goes into a certain state and it's like that for six hours or something, nobody's gonna be too upset. Um and I couldn't think of anything and uh so yeah, so then I just started building these gyms and I was like, I'm just gonna build the gyms and see where that takes me. I mean really, I feel like I'm just kind of pulling on a thread right now based on my personal curiosity and then just trying to also keep in mind like let's make sure this would also be useful for other people at some point, wherever that is. Ben  Yeah, I'm of course totally with you on the whole like it's tough to run this as because yeah, it is and yeah, I think about this the other day as this, this side project, I'm working on it, like, well it's it's actually right now just for fun, but of course it's like well how would I how to make money on this if I wanted to? And I could run a sad and this is a sad thing, it integrates with GIT hub. And uh so it's it's definitely a web based kind of stuff you do. Um Ben  but you know, if it went down for a few hours, people wouldn't be screaming like screaming about honey badger going down for a few hours. So like that's like that's okay. And then on the other hand, it's like, well it's it is very tightly integrated to get hub. So I could do a self hosted, here's a doctor image kind of thing, you go run this and it talks to your get up enterprise installation behind your firewall. Right? Ben  So I think, yeah, it's really good for entrepreneurs today who are so low to be thinking about that because there are a lot of options. There's the, you know, there's a psychic model. We just give one some someone some code, right? They license it, they run it and it's it's all them right. Or maybe you build a SAAS app that is also a docker image that they can deploy themselves. Maybe the codes available, you know, as maybe it's an open source thing, even like a matter most right, you can they have a hosted option, they have an open source options, have a self host adoption. Um Yeah, I think really good to be thinking about these things as you're, you know, deciding what you're doing day to day because it does, does affect quality of life. Like Ben  my first thought was, and I was when I think about this says I was like this side project, as I says, I was like, well then I got to have the laptop in the night time because Garrett  I'm like, I think I would much rather have an imac, but like as long as I'm involved in anything that can go offline, I don't think I can survive with just an imac, I've got to have a laptop and like yeah, I don't like that, feel like, I don't know, I mean, I don't think anybody but uh Yeah, Ben  Yeah, well that's, and I sometimes I think about a kind of metal level like oh that's a problem to solve, like how do you help? So the entrepreneurs run saAS operations without having to be, you know, always on like yeah, that's an unsolved problem. If someone solves that, that will be I think worth some. I mean Hiroko has done a pretty good job solving that problem, but it's not % solved yet. Garrett  So Well there's Ben  for me, Garrett  like I built a job board for our community here in the valley um because tourism based economies like the turnover and stuff is high and ah and so like for me I was staying with that and I haven't done this because it's just not critical enough. Um but the only thing I thought it would be like with a job board, if you could have it fall into read only mode where it's basically heavily cached on the front end and that's something that could work. But most apps where you're interacting with them because posting jobs, it's not like you constantly post jobs, you post a job and if you can't post a job right now you can come back in six hours and that's fine. It's not the end of the day, you know, into the world. Garrett  Uh but that's the only thing I've been able to come up with that has felt like it wouldn't be a huge issue as long as you designed and built it, right, so that I could do that. But everything else I'm like, nope, that won't work, That won't work. Like, I think that's why haven't start another business yet is because I've become really picky, like after selling stuff to, I'm like, what do I really want to do and not do again? And so much of the sad stuff while it's great. Um it was just like, it took a toll. Like, it made me not want to do so many things that now I love doing, like camping and hiking and like getting out of cell service. Um, and so I don't want to give that up anymore. Ben  So I guess the moral of the story is do all that kind of stuff when you're in your twenties have plenty of energy, right? You don't hate it yet, right? And then try to come up with something different by the time you're in your s, Garrett  use the experience to uh more wisely choose your battles. Ben  Yeah. Right. Yeah. Yeah. Cool. Well, this has been total fun. Yeah. Yeah. Garrett  Glad, Glad to catch up. Ben  Is there anything that we should have talked about that we didn't? Garrett  Oh, probably a ton of stuff. Uh, no, I mean, I wish this stuff was all in a better state. Many test heat is good to use now, I need to add a little bit more exception handling because now every now and then something goes wrong with many test heat and like you can't see your own test failures because it fell over. Uh so that's kind of my next step is to add some resiliency to that so that if it breaks, it says, hey many test heat fell over on this, but your things fine and have some like simple output. So you at least can see something because every now and then I have to go disable it and switch back to the regular reporter so I can actually see the the failure. Um but uh you know, it's ready to use, I'm using it Garrett  every day on all my projects now. Um and it's been pretty, pretty fine. Today was the first time in like a week that I've seen any kind of issue that didn't work so that people can use it. It definitely needs some tidying up and improvements, but that's forthcoming, then reviewer will hopefully be the end of the year will kind of see how, how things shake out with the holidays and all that, how much work I'm able to get done, but um I'm optimistic because I want it, I want to use it on other projects, like every time I go work on reviewer, I'm like, I really wish I had this for my other projects where I've just got dumb scripts that just run the same commands in order and you know, it's close, but it's not the same. Um Garrett  you know, I'm really excited about how much I know it's going to help my day to day work flow and I'm hopeful anybody else that's using rubio find those same benefits. Um And hopefully other languages too. I don't know. I haven't really tried, I mean in theory, javascript and a lot of that stuff will work like with the rails app. Um and like er be learning and and what night. Um So hopefully, but I haven't tried anything wholly outside of a ruby project to see if it could be useful there, but it should be, it's just a wrapper around command line, right? Strings. So hopefully Ben  and then next step V. S. Code plug in right where it's all just running all the time Garrett  code, right? Ben  Yeah, maybe that's your thing you sell. I don't know. Garrett  Yeah. You know, I haven't thought about that too much because most of them you can plug in on their own. Uh But then that gets overwhelming when you're trying to edit your file and it's like just yelling at you about everything. Like just let me think first, then yell at me after the fact after I've like figured it out. Yeah, I'm excited about it. It's kind of the most fun I've had programming in a long time. Um So we'll see. Ben  I love it. Well, scratching your niche is always fun and if you can make some money while you're at it. Hey, even funny Garrett  right? Well and so like that's the thing, like just kind of circle back and wrap it up, like part of it is in order for me to really pursue adaptable, I've got to have some kind of automatic income and like with sifter that would've been perfect, you know, it's recurring revenues, Great. And uh so a lot of it too is like, I'm really gonna unlock adaptable potential. I need to not be, you know, have an income tied to hourly rates. It's got to be divorced from how much time I'm actually sitting at my computer and uh so that's kind of been a driver too, but again, more just wandering and figuring it out, hoping it all comes together somehow. Ben  That's, we're all in the same boat. Garrett  Right, Ben  well, we will definitely link up uh the heat map and review and uh definitely get some people check it out if you're ruby ist and we'll link up your twitter so people can follow you and keep track of what you're doing. Uh Thanks again, yeah, hanging out with, Garrett  thanks. Great to catch up Ben  and thanks everybody for listening Again, you've been listening to found request from the founders of honey badger. We're excited to continue to bring you exciting episodes on podcast and a fantastic product, honey badger of course. So check us out on the bed, radio and you know, as star always says, review as if you like and don't review us, if you don't like, have a great one. 

The Iconic Albums series takes a detour and names the top nine motion pictures featuring cool guitar stuff. Good times!   Please note - Matt's audio is a little sketchy at first but rapidly improves, Rob and Gabor sound delightful throughout as usual!   Rob Rhodes  www.rhodetripent.com Gabor Josika SuperFunAwesomeHappyTime Pedal Show   This episode is brought to you by Fretboard Biology    Fretboard Biology - the online guitar college created by Joe Elliott, ex Head of Guitar at GIT and McNally Smith Music College. Fretboard Biology Guitar Speak Podcast #146 - Joe Elliott - ex guitar head of GIT - launches Fretboard Biology Guitar Speak Podcast Links PayPal Tip Jar Visit us at guitarspeakpodcast.com Subscribe and find previous episodes at: Apple Podcasts Spotify Stitcher   Follow us on Facebook & Instagram Buy a T-Shirt! Contact us at guitarspeakpodcast@gmail.com

Felipe Nevola is the CEO of MeteorJS. He jumps in to discuss the changes and updates to Meteor over the last several years. He explains what Meteor is, what its history is, and how it lands within the current JavaScript ecosystem. You can use it to build web and mobile apps and is a mature option to use for your applications. Panel Aimee KnightAJ O'NealCharles Max WoodDan ShappirSteve Edwards Guest Filipe Névola Sponsors Shortcut (formerly Clubhouse.io)Dev Influencers AcceleratorLevel Up | Devchat.tv Links MeteorGitHub | meteor/examplesGitHub | meteor/meteorMeteorjs - YouTubemeteor.js - InstagramTwitter: Meteor ( @meteorjs )JSJ 439: More Jabber About Less JavaScript with Alex Russell - Devchat.tvHow To Create An AppHow to Create an App - YouTubefilipenevola - InstagramTwitter: Filipe Névola ( @FilipeNevola ) Picks AJ- GitHub | therootcompany/passphrase.jsAJ- An ISP That Believes in the Constitution | TransmissionAJ- court orders | unconstitutional | customer data :: USA - XMissionAJ- customer privacy | transparency | safeguard your rights :: USA - XMissionAJ- The Final Empire: Mistborn Book 1 Charles- PodcastBootcamp.ioCharles- Tribe of MillionairesCharles- GrooveFunnelsCharles- Riverside.fmDan- Taking micro-frontends to the next level | by Shahar Talmi | MediumDan- Hobson's Browser - Infrequently NotedFilipe- How To Create An AppFilipe- lemeno.io Contact Aimee: Aimee Knight – Software Architect, and International Keynote SpeakerGitHub: Aimee Knight ( AimeeKnight )Twitter: Aimee Knight ( @Aimee_Knight )LinkedIn: Aimee K.aimeemarieknight | InstagramAimee Knight | Facebook Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode )coolaj86- Twitch Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact Dan: GitHub: Dan Shappir ( DanShappir )LinkedIn: Dan ShappirTwitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards Special Guest: Filipe Névola.

Felipe Nevola is the CEO of MeteorJS. He jumps in to discuss the changes and updates to Meteor over the last several years. He explains what Meteor is, what its history is, and how it lands within the current JavaScript ecosystem. You can use it to build web and mobile apps and is a mature option to use for your applications. Panel Aimee KnightAJ O'NealCharles Max WoodDan ShappirSteve Edwards Guest Filipe Névola Sponsors Shortcut (formerly Clubhouse.io)Dev Influencers AcceleratorLevel Up | Devchat.tv Links MeteorGitHub | meteor/examplesGitHub | meteor/meteorMeteorjs - YouTubemeteor.js - InstagramTwitter: Meteor ( @meteorjs )JSJ 439: More Jabber About Less JavaScript with Alex Russell - Devchat.tvHow To Create An AppHow to Create an App - YouTubefilipenevola - InstagramTwitter: Filipe Névola ( @FilipeNevola ) Picks AJ- GitHub | therootcompany/passphrase.jsAJ- An ISP That Believes in the Constitution | TransmissionAJ- court orders | unconstitutional | customer data :: USA - XMissionAJ- customer privacy | transparency | safeguard your rights :: USA - XMissionAJ- The Final Empire: Mistborn Book 1 Charles- PodcastBootcamp.ioCharles- Tribe of MillionairesCharles- GrooveFunnelsCharles- Riverside.fmDan- Taking micro-frontends to the next level | by Shahar Talmi | MediumDan- Hobson's Browser - Infrequently NotedFilipe- How To Create An AppFilipe- lemeno.io Contact Aimee: Aimee Knight – Software Architect, and International Keynote SpeakerGitHub: Aimee Knight ( AimeeKnight )Twitter: Aimee Knight ( @Aimee_Knight )LinkedIn: Aimee K.aimeemarieknight | InstagramAimee Knight | Facebook Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode )coolaj86- Twitch Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact Dan: GitHub: Dan Shappir ( DanShappir )LinkedIn: Dan ShappirTwitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards Special Guest: Filipe Névola.

About ScottScott first typed ‘docker run' in 2013 and hasn't looked back. He's been with Docker since 2014 in a variety of leadership roles and currently serves as CEO. His experience previous to Docker includes Sun Microsystems, Puppet, Netscape, Cisco, and Loudcloud (parent of Opsware). When not fussing with computers he spends time with his three kids fussing with computers.Links: Docker: https://www.docker.com Twitter: https://twitter.com/scottcjohnston 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 Liquibase. If you're anything like me, you've screwed up the database part of a deployment so severely that you've been banned from touching every anything that remotely sounds like SQL, at at least three different companies. We've mostly got code deployments solved for, but when it comes to databases we basically rely on desperate hope, with a roll back plan of keeping our resumes up to date. It doesn't have to be that way. Meet Liquibase. It is both an open source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails to ensure you'll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at liquibase.com. Offer does not apply to Route 53.Corey: This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals. Having the highest quality content in tech and cloud skills, and building a good community the is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. Its both useful for individuals and large enterprises, but here's what makes it new. I don't use that term lightly. Cloud Academy invites you to showcase just how good your AWS skills are. For the next four weeks you'll have a chance to prove yourself. Compete in four unique lab challenges, where they'll be awarding more than $2000 in cash and prizes. I'm not kidding, first place is a thousand bucks. Pre-register for the first challenge now, one that I picked out myself on Amazon SNS image resizing, by visiting cloudacademy.com/corey. C-O-R-E-Y. That's cloudacademy.com/corey. We're gonna have some fun with this one!Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Once upon a time, I started my public speaking career as a traveling contract trainer for Puppet; I've talked about this before. And during that time, I encountered someone who worked there as an exec, Scott Johnston, who sat down, talked to me about how I viewed things, and then almost immediately went to go work at Docker instead. Today's promoted episode brings Scott on to the show. Scott, you fled to get away from me, became the CEO of Docker over the past, oh what is it, seven years now. You're still standing there, and I'm not making fun of Docker quite the way that I used to. First, thanks for joining me.Scott: Great to be here, Corey. Thanks for the invitation. I'm not sure I was fleeing you, but we can recover that one at another time.Corey: Oh, absolutely. In that era, one of my first talks that I started giving that anyone really paid any attention to was called, “Heresy in the Church of Docker,” where I listed about 10 to 13 different things that Docker didn't seem to have answers for, like network separation, security, audit logging, et cetera, et cetera. And it was a fun talk that I used to basically learn how to speak publicly without crying before and after the talk. And in time, it wound up aging out as these problems got addressed, but what surprised me at the time was how receptive the Docker community was to the idea of a talk that wound up effectively criticizing something that for, well, a number of them it felt a lot of the time like it wasn't that far from a religion; it was very hype-driven: “Docker, Docker, Docker” was a recurring joke. Docker has changed a lot. The burning question that I think I want to start this off with is that it's 2021; what is Docker? Is it a technology? Is it a company? Is it a religion? Is it a community? What is Docker?Scott: Yes. I mean that sincerely. Often, the first awareness or the first introduction that newcomers have is in fact the community, before they get their hands on the product, before they learn that there's a company behind the product is they have a colleague who is, either through a Zoom or sitting next to them in some places, or in a coffee shop, and says, “Hey, you got to try this thing called Docker.” And they lean over—either virtually or physically—and look at the laptop of their friend who's promoting Docker, and they see a magical experience. And that is the introduction of so many of our community members, having spoken with them and heard their own kind of journeys.And so that leads to like, “Okay, so why the excitement? Why did the friend lean over to the other friend and introduce?” It's because the tools that Docker provides just helps devs get their app built and shipping faster, more securely, with choice, without being tied into any particular runtime, any particular infrastructure. And that combination has proven to be a breakthrough dopamine hit to developers since the very beginning, since 2013, when Docker is open-source.Corey: It feels like originally, the breakthrough of Docker, that people will say, “Oh, containers aren't new. We've had that going back to LPARs on mainframes.” Yes, I'm aware, but suddenly, it became easy to work with and didn't take tremendous effort to get unified environments. It was cynically observed at the time by lots of folks smarter than I am, that the big breakthrough Docker had was how to make my MacBook look a lot more like a Linux server in production. And we talk about breaking down silos between ops and dev, but in many ways, this just meant that the silo became increasingly irrelevant because, “Works on my machine” was no longer a problem.“Well, you better back up your email because your laptop's about to go into production in that case.” Containers made it easier and that was a big deal. It seems, on some level, like there was a foray where Docker the company was moving into the world of, “Okay, now we're going to run a lot of these containers in production for you, et cetera.” It really feels like recently, the company as a whole and the strategy has turned towards getting back to its roots of solving developer problems and positioning itself as a developer tool. Is that a fair characterization?Scott: A hundred percent. That's very intentional, as well. We certainly had good products, and great customers, and we're solving problems for customers on the ops side, I'll call it, but when we stood back—this is around 2019—and said, “Where's the real… joy?” For lack of a better word, “Where's the real joy from a community standpoint, from a product experience standpoint, from a what do we do different and better and more capable than anyone else in the ecosystem?” It was that developer experience. And so the reset that you're referring to in November 2019, was to give us the freedom to go back and just focus the entire company's efforts on the needs of developers without any other distractions from a revenue, customer, channel, so on and so forth.Corey: So, we knew this was going to come up in the conversation, but as of a couple of weeks ago—as of the time of this recording—you announced a somewhat, well, let's say controversial change in how the pricing and licensing works. Now, as of—taking effect at the end of this year—the end of January, rather, of next year—Docker Desktop is free for folks to use for individual use, and that's fine, and for corporate use, Docker Desktop also remains free until you are a large company defined by ten million in revenue a year and/or 250 employees or more. And that was interesting and I don't think I'd seen that type of requirement placed before on what was largely an open-source project that's now a developer tool. I believe there are closed-source aspects of it as well for the desktop experience, but please don't quote me on that; I'm not here to play internet lawyer engineer. But at that point, the internet was predictably upset about this because it is easy to yell about any change that is coming, regardless.I was less interested in that than I am in what the reception has been from your corporate customers because, let's be clear, users are important, community is important, but goodwill will not put food on the table past a certain point. There has to be a way to make a company sustainable, there has to be a recurring revenue model. I realize that you know this, but I'm sure there are people listening to this who are working in development somewhere who are, “Wait, you mean I need to add more value than I cost?” It was a hard revelation for [laugh] me back when I had been in the industry a few years—Scott: [laugh]. Sure.Corey: —and I'm still struggling with that—Scott: Sure.Corey: Some days.Scott: You and me both. [laugh].Corey: So, what has the reaction been from folks who have better channels of communicating with you folks than angry Twitter threads?Scott: Yeah. Create surface area for a discussion, Corey. Let's back up and talk on a couple points that you hit along the way there. One is, “What is Docker Desktop?” Docker Desktop is not just Docker Engine.Docker Desktop is a way in which we take Docker Engine, Compose, Kubernetes, all important tools for developers building modern apps—Docker Build, so on and so forth—and we provide an integrated engineered product that is engineered for the native environments of Mac and Windows, and soon Linux. And so we make it super easy to get the container runtime, Kubernetes stack, the networking, the CLI, Compose, we make it super easy just to get that up and running and configured with smart defaults, secured, hardened, and importantly updated. So, any vulnerabilities patched and so on and so forth. The point is, it's a product that is based on—to your comments—upstream open-source technologies, but it is an engineered commercial product—Docker Desktop is.Corey: Docker Desktop is a fantastic tool; I use it myself. I could make a bunch of snide comments that on Mac, it's basically there to make sure the fans are still working on the laptop, but again, computers are hard. I get that. It's incredibly handy to have a graphical control panel. It turns out that I don't pretend to understand those people, but some folks apparently believe that there are better user interfaces than text and an 80-character-wide terminal window. I don't pretend to get those people, but not everyone has the joy of being a Linux admin for far too long. So, I get it, making it more accessible, making it easy, is absolutely worth using.Scott: That's right.Corey: It's not a hard requirement to run it on a laptop-style environment or developer workstation, but it makes it really convenient.Scott: Before Docker desktop, one had to install a hypervisor, install a Linux VM, install Docker Engine on that Linux VM, bridge between the VM and the local CLI on the native desktop—like, lots of setup and maintenance and tricky stuff that can go wrong. Trust me how many times I stubbed my own toes on putting that together. And so Docker Desktop is designed to take all of that setup nonsense overhead away and just let the developer focus on the app. That's what the product is, and just talking about where it came from, and how it uses these other upstream technologies. Yes, and so we made a move on August 31, as you noted, and the motivation was the following: one is, we started seeing large organizations using Docker Desktop at scale.When I say ‘at scale,' not one or two or ten developers; like, hundreds and thousands of developers. And they were clamoring for capabilities to help them manage those developer environments at scale. Second is, we saw them getting a lot of benefit in terms of productivity, and choice, and security from using Docker Desktop, and so we stood back and said, “Look, for us to scale our business, we're at 10-plus million monthly active developers today. We know there's 45 million developers coming in this decade; how do we keep scaling while giving a free experience, but still making sure we can fund our engineers and deliver features and additional value?” We looked at other projects, Corey.The first thing we did is we looked outside our four walls, said, “How have other projects with free and open-source components navigated these waters?” And so the thresholds that you just mentioned, the 250 employees and the ten million revenue, were actually thresholds that we saw others put in place to draw lines between what is available completely for free and what is available for those users that now need to purchase subscription if they're using it to create value for their organizations. And we're very explicit about that. You could be using Docker for training, you could be using Docker for eval in those large organizations; we're not going to chase you or be looking to you to step up to a subscription. However, if you're using Docker Desktop in those environments, to build applications that run your business or that are creating value for your customers, then purchasing a subscription is a way for us to continue to invest in a product that the ecosystem clearly loves and is getting a lot of value out of. And so, that was again, the premise of this change. So, now to the root of your question is, so what's the reaction? We're very, very pleased. First off, yes, there were some angry voices out there.Corey: Yeah. And I want to be clear, I'm not trivializing people who feel upset.Scott: No.Corey: When you're suddenly using a thing that is free and discovering that, well, now you have to pay money for it, people are not generally going to be happy about that.Scott: No.Corey: When people are viewed themselves as part of the community, of contributing to what they saw as a technical revolution or a scrappy underdog and suddenly they find themselves not being included in some way, shape or form, it's natural to be upset, I don't want to trivialize—Scott: Not at all.Corey: People's warm feelings toward Docker. It was a big part of a lot of folks' personality, for better or worse, [laugh] for a few years in there. But the company needs to be sustainable, so what I'm really interested in is what has that reaction been from folks who are, for better or worse, “Yes, yes, we love Docker, but I don't get to sign $100,000 deals because I just really like the company I'm paying the money to. There has to be business value attached to that.”Scott: That's right. That's right. And to your point, we're not trivializing either the reaction by the community, it was encouraging to see many community members got right away what we're doing, they saw that still, a majority of them can continue using Docker for free under the Docker Personal subscription, and that was also intentional. And you saw on the internet and on Twitter and other social media, you saw them come and support the company's moves. And despite some angry voices in there, there was overwhelmingly positive.So, to your question, though, since August 31, we've been overwhelmed, actually, by the positive response from businesses that use Docker Desktop to build applications and run their businesses. And when I say overwhelmed, we were tracking—because Docker Desktop has a phone-home capability—we had a rough idea of what the baseline usage of Docker Desktops were out there. Well, it turns out, in some cases, there are ten times as many Docker Desktops inside organizations. And the average seems to be settling in around three times to four times as many. And we are already closing business, Corey.In 12 business days, we have companies come through, say, “Yes, our developers use this product. Yes, it's a valuable product. We're happy to talk to a salesperson and give you over to procurement, and here we go.” So, you and I both been around long enough to know, like 12 working days to have a signed agreement with an enterprise agreement is unheard of.Corey: Yeah, but let's be very clear here, on The Duckbill Group's side of things where I do consulting projects, I sell projects to companies that are, “Great, this project will take, I don't know, four to six weeks, whatever it happens to be, and, yeah, you're going to turn a profit on this project in about the first four hours of the engagement.” It is basically push button and you will receive more money in your budget than you had when you started, and that is probably the easiest possible enterprise sale, and it still takes 60 to 90 days most of the time to close deals.Scott: That's right.Corey: Trying to get a procurement deal for software through enterprise procurement processes is one of those things when people say, “Okay, we're going to have a signature in Q3,” you have to clarify what year they're talking about. So, 12 days is unheard of.Scott: [laugh]. Yep. So, we've been very encouraged by that. And I'll just give you a rough numbers: the overall response is ten times our baseline expectations, which is why—maybe unanticipated question, or you going to ask it soon—we came back within two weeks—because we could see this curve hit right away on the 31st of August—we came back and said, “Great.” Now, that we have the confidence that the community and businesses are willing to support us and invest in our sustainability, invest in the sustainable, scalable Docker, we came and we accelerated—pulled forward—items in our roadmap for developers using Docker Desktop, both for Docker Personal, for free in the community, as well as the subscribers.So, things like Docker Desktop for Linux, right? Docker Desktop for Mac, Docker Desktop for Windows has been out there about five years, as I said. We have heard Docker Desktop for Linux rise in demand over those years because if you're managing a large number of developers, you want a consistent environment across all the developers, whether they're using Linux, Mac, or Windows desktops. So, Docker Desktop for Linux will give them that consistency across their entire development environment. That was the number two most requested feature on our public roadmap in the last year, and again, with the positive response, we're now able to confidently invest in that. We're hiring more engineers than planned, we're pulling that forward in the roadmap to show that yes, we are about growing and growing sustainably, and now that the environment and businesses are supporting us, we're happy to double down and create more value.Corey: My big fear when the change was announced was the uncertainty inherent to it. Because if there's one thing that big companies don't like, it's uncertainty because uncertainty equates to risk in their mind. And a lot of other software out there—and yes, Oracle Databases I am looking at you—have a historical track record of, “Okay, great. We have audit rights to inspect your environment, and then when we wind up coming in, we always find that there have been licensing shortfalls,” because people don't know how far things spread internally, as well as, honestly, it's accounting for this stuff in large, complex organizations is a difficult thing. And then there are massive fines at stake, and then there's this whole debate back and forth.Companies view contracts as if every company behaves like that when it comes down to per-seat licensing and the rest. My fear was that that risk avoidance in large companies would have potentially made installing Docker Desktop in their environment suddenly a non-starter across the board, almost to the point of being something that you would discipline employees for, which is not great. And it seems from your response, that has not been a widespread reaction. Yes of course, there's always going to be some weird company somewhere that does draconian things that we don't see, but the fact that you're not sitting here, telling me that you've been taking a beating from this from your enterprise buyers, tells me you're onto something.Scott: I think that's right, Corey. And as you might expect, the folks that don't reach out are silent, and so we don't see folks who don't reach out to us. But because so many have reached out to us so positively, and basically quickly gone right to a conversation with procurement versus any sort of back-and-forth or questions and such, tells us we are on the right track. The other thing, just to be really clear is, we did work on this before the August 31 announcement as well—this being how do we approach licensing and compliance and such—and we found that 80% of organizations, 80% of businesses want to be in compliance, they have a—not just want to be in compliance, but they have a history of being in compliance, regardless of the enforcement mechanism and whatnot. And so that gave us confidence to say, “Hey, we're going to trust our users. We're going to say, ‘grace period ends on January 31.'”But we're not shutting down functionality, we're not sending in legal [laugh] activity, we're not putting any sort of strictures on the product functionality because we have found most people love the product, love what it does for them, and want to see the company continue to innovate and deliver great features. And so okay, you might say, “Well, doesn't that 20% represent opportunity?” Yeah. You know, it does, but it's a big ecosystem. The 80% is giving us a great boost and we're already starting to plow that into new investment. And let's just start there; let's start there and grow from there.This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: I also have a hard time imagining that you and your leadership team would be short-sighted enough to say, “Okay, that”—even 20% of companies that are willing to act dishonestly around stuff like that seems awfully high to me, but assuming it's accurate, would tracking down that missing 20% be worth setting fire to the tremendous amount of goodwill that Docker still very much enjoys? I have a hard time picturing any analysis where that's even a question other than something you set up to make fun of.Scott: [laugh]. No, that's exactly right Corey, it wouldn't be worth it which is why again, we came out of the gate with like, we're going to trust our users. They love the community, they love the product, they want to support us—most of them want to support us—and, you know, when you have most, you're never going to get a hundred percent. So, we got most and we're off to a good start, by all accounts. And look, a lot of folks too sometimes will be right in that gray middle where you let them know that they're getting away with something they're like, “All right, you caught me.”We've seen that behavior before. And so, we can see all this activity out there and we can see if folks have a license or compliance or not, and sometimes just a little tap on the shoulder said, “Hey, did you know that you might be paying for that?” We've seen most folks at the time say, “Ah, okay. You caught me. Happy to talk to procurement.”So, this does not have to be heavy-handed as you said, it does not have to put at risk the goodwill of the 80%. And we don't have to get a hundred percent to have a great successful business and continuing successful community.Corey: Yeah. I'll also point out that, by my reading of your terms and conditions and how you've specified this—I mean, this is not something I've asked you about, so this could turn into a really awkward conversation but I'm going to roll with it anyway, it explicitly states that it is and will remain free for personal development.Scott: That is correct.Corey: When you're looking at employees who work at giant companies and have sloppy ‘bring your own device' controls around these things, all right, they have it installed on their work machine because in their spare time, they're building an app somewhere, they're not going to get a nasty gram, and they're not exposing their company to liability by doing that?Scott: That is exactly correct. And moreover, just keep looking at those use cases, if the company is using it for internal training or if the company is using it to evaluate someone else's technology, someone else's software, all those cases are outside the pay-for subscription. And so we believe it's quite generous in allowing of trials and tests and use cases that make it accessible and easy to try, easy to use, and it's just in the case where if you're a large organization and your developers are using it to build applications for your business and for your customers, thus you're getting a lot of value using the product, we're asking you to share that value with us so we can continue to invest in the product.Corey: And I think that's a reasonable expectation. The challenge that Docker seems to have had for a while has been that the interesting breakthrough, revelatory stuff that you folks did was all open-source. It was a technology that was incredibly inspired in a bunch of different ways. I am, I guess, mature enough to admit that my take that, “Oh, Docker is terrible”—which was never actually my take—was a little short-sighted. I'm very good at getting things wrong across the board, and that is no exception.I also said virtualization was a flash in the pan and look how that worked out. I was very anti-cloud, et cetera, et cetera. Times change, people change, and doubling down on being wrong gains you nothing. But the question that was always afterwards what is the monetization strategy? Because it's not something you can give away for free and make it up in volume?Even VC money doesn't quite work like that forever, so there's a—the question is, what is the monetization strategy that doesn't leave people either resenting you because, “Remember that thing that used to be free isn't anymore? Doesn't it suck to be you?” And is still accessible as broadly as you are, given the sheer breadth and diversity of your community? Like I can make bones about the fact that ten million in revenue and 250 employees are either worlds apart, or the wrong numbers, or whatever it is, but it's not going to be some student somewhere sitting someplace where their ramen budget is at risk because they have to spend $5 a month or whatever it is to have this thing. It doesn't apply to them.And this feels like, unorthodox though it certainly is, it's not something to be upset about in any meaningful sense. The people that I think would actually be upset and have standing to be upset about this are the enterprise buyers, and you're hearing from them in what is certainly—because I will hear it if not—that this is something they're happy about. They are thrilled to work with you going forward. And I think it makes sense. Even when I was doing stuff as an independent consultant, before I formalized the creation of The Duckbill Group and started hiring people, my policy was always to not use the free tier of things, even if I fit into them because I would much rather personally be a paying customer, which elevates the, I guess, how well my complaints are received.Because I'm a free user, I'm just another voice on Twitter; albeit a loud one and incredibly sarcastic one at times. But if I'm a paying customer, suddenly the entire tenor of that conversation changes, and I think there's value to that. I've always had the philosophy of you pay for the things you use to make money. And that—again, that is something that's easy for me to say now. Back when I was in crippling debt in my 20s, I assure you, it was not, but I still made the effort for things that I use to make a living.Scott: Yeah.Corey: And I think that philosophy is directionally correct.Scott: No, I appreciate that. There's a lot of good threads in there. Maybe just going way back, Docker stands on the shoulders of giants. There was a lot of work with container tech in the Linux kernel, and you and I were talking before about it goes back to LPAR on IBMs, and you know, BS—Berkeley's—Corey: BSD jails and chroots on Linux. Yeah.Scott: Chroot, right? I mean, Bill Joy, putting chroot in—Corey: And Tupperware parties, I'm sure. Yeah.Scott: Right. And all credit to Solomon Hykes, Docker's founder, who took a lot of good up and coming tech—largely on the ops side and in Linux kernel—took the primitives from Git and combined that with immutable copy-on-write file system and put those three together into a really magical combination that simplified all this complexity of dependency management and portability of images across different systems. And so in some sense, that was the magic of standing on these giant shoulders but seeing how these three different waves of innovation or three different flows of innovation could come together to a great user experience. So, also then moving forward, I wouldn't say they're happy, just to make sure you don't get inbound, angry emails—the enterprise buyers—but they do recognize the value of the product, they think the economics are fair and straight ahead, and to your point about having a commercial relationship versus free or non-existing relationship, they're seeing that, “Oh, okay, now I have insight into the roadmap. Now, I can prioritize my requirements that my devs have been asking for. Now, I can double-down on the secure supply chain issues, which I've been trying to get in front of for years.”So, it gives them an avenue that now, much different than a free user as you observed, it's a commercial relationship where it's two way street versus, “Okay, we're just going to use this free stuff and we don't have much of a say because it's free, and so on and so forth.” So, I think it's been an eye-opener for both the company but also for the businesses. There is a lot of value in a commercial relationship beyond just okay, we're going to invest in new features and new value for developers.Corey: The challenge has always been how do you turn something that is widely beloved, that is effectively an open-source company, into money? There have been a whole bunch of questions about this, and it seems that the consensus that has emerged is that a number of people for a long time mistook open-source for a business model instead of a strategy, and it's very much not. And a lot of companies are attempting to rectify that with weird license changes where, “Oh, you're not allowed to take our code and build a service out of it if you're a cloud provider.” Amazon's product strategy is, of course, “Yes,” so of course, there's always going to be something coming out of AWS that is poorly documented, has a ridiculous name, and purports to do the same thing for way less money, except magically you pay them by the hour. I digress.Scott: No, it's a great surface area, and you're right I completely didn't answer that question. [laugh]. So—Corey: No, it's fair. It's—Scott: Glad you brought it back up.Corey: —a hard problem. It's easy to sit here and say, “Well, what I think they should do”—but all of those solutions fall apart under ten seconds of scrutiny.Scott: Super, super hard problem which, to be fair, we as a team and a community wrestled with for years. But here's where we landed, Corey. The short version is that you can still have lots of great upstream open-source technologies, and you'll have an early adopter community that loves those, use those, gets a lot of progress running fast and far with those, but we've found that the vast majority of the market doesn't want to spend its time cobbling together bits and bytes of open-source tech, and maintaining it, and patching it, and, and, and. And so what we're offering is an engineered product that takes the upstream but then adds a lot of value—we would say—to make it an engineered, easy to use, easy to configure, upgraded, secure, so on and so forth. And the convenience of that versus having to cobble together your own environment from upstream has proved to be what folks are willing to pay for. So, it's the classic kind of paying for time and convenience versus not.And so that is one dimension. And the other dimension, which you already referenced a little bit with AWS is that we have SaaS; we have a SaaS product in Docker Hub, which is providing a hosted registry with quality content that users know is updated not less than every 30 days, that is patched and maintained by us. And so those are examples of, in some sense, consumption [unintelligible 00:27:53]. So, we're using open-source to build this SaaS service, but the service that users receive, they're willing to pay for because they're not having to patch the Mongo upstream, they're not having to roll the image themselves, they're not having to watch the CVEs and scramble when everything comes out. When there's a CVE out in our upstream, our official images are patched no less than 24 hours later and typically within hours.That's an example of a service, but all based on upstream open-source tech that for the vast majority of uses are free. If you're consuming a lot of that, then there's a subscription that kicks in there as well. But we're giving you value in exchange for you having to spend your time, your engineers, managing all that that I just walked through. So, those are the two avenues that we found that are working well, that seem to be a fair trade and fair balance with the community and the rest of the ecosystem.Corey: I think the hardest part for a lot of folks is embracing change. And I have encountered this my entire career where I started off doing large-scale email systems administration, and hey, turns out that's not really a thing anymore. And I used to be deep in the bowels of Postfix, for example. I'm referenced in the SVN history of Postfix, once upon a time, just for helping with documentation and finding weird corner cases because I'm really good at breaking things by accident. And I viewed it as part of my identity.And times have changed and moved on; I don't run Postfix myself for anything anymore. I haven't touched it in years. Docker is still there and it's still something that people are actively using basically everywhere. And there's a sense of ownership and identity for especially early adopters who glom on to it because it is such a better way of doing some things that it is almost incomprehensible that we used to do it any other way. That's transformation.That's something awesome. But people want to pretend that we're still living in that era where technology has not advanced. The miraculous breakthrough in 2013 is today's de rigueur type of environment where this is just, “Oh, yeah. Of course you're using Docker.” If you're not, people look at you somewhat strangely.It's like, “Oh, I'm using serverless.” “Okay, but you can still build that in Docker containers. Why aren't you doing that?” It's like, “Oh, I don't believe in running anything that doesn't make me pay AWS by the second.” So okay, great. People are going to have opinions on this stuff. But time marches on and whatever we wish the industry would do, it's going to make its own decisions and march forward. There's very little any of us can do to change that.Scott: That's right. Look, it was a single container back in 2013, 2014, right? And now what we're seeing—and you kind of went there—is we're separating the implementation of service from the service. So, the service could be implemented with a container, could be a serverless function, could be a hosted XYZ as a service on some cloud, but what developers want to do is—what they're moving towards is, assemble your application based on services regardless of the how. You know, is that how a local container? To your point, you can roll a local serverless function now in an OCI image, and push it to Amazon.Corey: Oh, yeah. It's one of that now 34 ways I found to run containers on AWS.Scott: [laugh]. You can also, in Compose, abstract all that complexity away. Compose could have three services in it. One of those services is a local container, one of those services might be a local serverless function that you're running to test, and one of those services could be a mock to a Database as a Service on a cloud. And so that's where we are.We've gone beyond the single-container Docker run, which is still incredibly powerful but now we're starting to uplevel to applications that consist of multiple services. And where do those services run? Increasingly, developers do not need to care. And we see that as our mission is continue to give that type of power to developers to abstract out the how, extract out the infrastructure so they can just focus on building their app.Corey: Scott, I want to thank you so much for taking the time to speak with me. If people want to learn more—and that could mean finding out your opinions on things, potentially yelling at you about pricing changes, more interestingly, buying licenses for their large companies to run this stuff, and even theoretically, since you alluded to it a few minutes ago, look into working at Docker—where can they find you?Scott: No, thanks, Corey. And thank you for the time to discuss and look back over both years, but also zoom in on the present day. So, www.docker.com; you can find any and all what we just walked through. They're more than happy to yell at me on Twitters at @scottcjohnston, and we have a public roadmap that is in GitHub. I'm not going to put the URL here, but you can find it very easily. So, we love hearing from our community, we love engaging with them, we love going back and forth. And it's a big community; jump in, the waters warm, very welcoming, love to have you.Corey: And we'll of course, but links to that in the [show notes. 00:32:28] Thank you so much for your time. I really do appreciate it.Scott: Thank you, Corey. Right back at you.Corey: Scott Johnston, CEO of Docker. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment telling me that Docker isn't interested in at all because here's how to do exactly what Docker does in LPARs on your mainframe until the AWS/400 comes to [unintelligible 00:33:02].Scott: [laugh].Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

0:00 Cold Open 1:15 Coming Up 1:50 Banter - Gitea in Docker 11:48 History: Garuda 52:27 Thoughts: Garuda 1:15:42 Housekeeping 1:21:36 App Focus 1:33:46 Next Time 1:35:28 Thank You 1:36:24 Stinger Patreon. (https://patreon.com/linuxuserspace) Youtube. (https://linuxuserspace.show/youtube) Twitter. (https://linuxuserspace.show/twitter) Odysee. (https://linuxuserspace.show/odysee) Discord. (https://linuxuserspace.show/discord) Telegram. (https://linuxuserspace.show/telegram) Matrix. (https://linuxuserspace.show/matrix) Reddit. (https://linuxuserspace.show/reddit) Coming up in this episode 1. Leo got tea in Docker 2. We teach you how to train your Dragon 3. We fly like an eagle 4. Our app pick helps Leo install Mac and Windows Banter - Tea Time, come and Git it. Gitea (https://gitea.com) Garuda Linux Garuda Linux (https://garudalinux.org/) Wikipedia page for Garuda (https://en.wikipedia.org/wiki/Garuda_Linux) Gnome was almost officially dropped (https://forum.garudalinux.org/t/dropping-gnome-for-good/77) The site gets its first revamp. (https://forum.garudalinux.org/t/new-look-for-the-website/140) Calamares gets a facelift (https://forum.garudalinux.org/t/new-calamares-outfit/134) The Ultimate Edition is killed (https://forum.garudalinux.org/t/garuda-linux-release-200726/155) performance-tweaks is introduced (https://forum.garudalinux.org/t/performance-tweaks/194) Wayfire is official (https://forum.garudalinux.org/t/garuda-linux-release-200726/155) Distrowatch Review (https://distrowatch.com/weekly.php?issue=20200921#garuda) 9to5 Linux coverage (https://9to5linux.com/arch-linux-based-garuda-linux-gaming-distro-now-supports-snap-and-flatpak-apps) btrfs subvolume layout's current form is finalized (https://forum.garudalinux.org/t/garuda-linux-golden-eagle-iso-refresh-201022/1051) The iconic Garuda look is added. (https://forum.garudalinux.org/t/garuda-linux-imperial-eagle-201205/1774) Starship shell (https://starship.rs/) Firedragon, Librewolf fork which is a Firefox fork, becomes the default browser. (https://forum.garudalinux.org/t/firedragon-librewolf-fork/5018/163) Chaotic AUR turns three! (https://forum.garudalinux.org/t/chaotic-aur-turns-three-years-old/13502) Site: garudalinux.org formerly garudalinux.in Base System: Arch Desktop Environment: Flagship: Plasma File Manager: Flagship: Dolphin Package Manager: pacman Kernel: Most Up To Date Zen Kernel Display Manager: Flagship: SDDM Display Protocol: Wayland or X11 Project Leaders: Librewish, SGS & Dragonfire Other Team Members (https://garudalinux.org/about.html) Housekeeping mintCast (https://mintcast.org) Email us - contact@linuxuserspace.show Linux User Space Discord Server (https://linuxuserspace.show/discord) Our Matrix room (https://linuxuserspace.show/matrix) Support us at Patreon (https://patreon.com/linuxuserspace) Join us on Telegram (https://linuxuserspace.show/telegram) Follow us on Twitter (https://twitter.com/LinuxUserSpace) Watch us on YouTube (https://linuxuserspace.show/youtube) Or Watch us on Odysee (https://linuxuserspace.show/odysee) Our latest social platform reddit (https://linuxuserspace.show/reddit) Check out our website https://linuxuserspace.show App Focus Quickemu This episode's app: * Quickemu (https://github.com/wimpysworld/quickemu) Next Time With us trying out Garuda Linux for this past month, that means our next show will be topic based. We have a few topics planned for you and all of them will affect you in the Linux User Space. Our next distro to check out is Zorin OS (https://zorin.com/os/) Join us in two weeks when we return to the Linux User Space Stay tuned on Twitter, Telegram, Matrix, Discord, Reddit whatever. Join the conversation. Talk to us, and give us more ideas. We would like to acknowledge our top patrons. Thank you for your support! Contributor Nicholas CubicleNate LiNuXsys666 Jill and Steve WalrusZ sleepyeyesvince Co-Producer Donnie Johnny Producer Bruno John

Today we turn the tables on our 'Iconic Albums' co-host Rob Rhodes. Rob is a brilliant musician with killer guitar and business chops who shares wisdom from years of experience in many facets of the live entertainment industry. Of course, Rob is happiest when wailing away on a six string so there is plenty of guitar talk too!   Rob Rhodes - www.rhodetripent.com   This episode is brought to you by Fretboard Biology  Fretboard Biology - the online guitar college created by Joe Elliott, ex Head of Guitar at GIT and McNally Smith Music College. Fretboard Biology Guitar Speak Podcast #146 - Joe Elliott - ex guitar head of GIT - launches Fretboard Biology Guitar Speak Podcast Links PayPal Tip Jar Visit us at guitarspeakpodcast.com Subscribe and find previous episodes at: Apple Podcasts Spotify Stitcher   Follow us on Facebook & Instagram

Matt, Gabor & Rob check out the Foo Fighters' third album "There Is Nothing Left To Lose".   Rob Rhodes  www.rhodetripent.com Gabor Josika SuperFunAwesomeHappyTime Pedal Show   This episode is brought to you by Fretboard Biology  Fretboard Biology - the online guitar college created by Joe Elliott, ex Head of Guitar at GIT and McNally Smith Music College. Fretboard Biology Guitar Speak Podcast #146 - Joe Elliott - ex guitar head of GIT - launches Fretboard Biology Guitar Speak Podcast Links PayPal Tip Jar Visit us at guitarspeakpodcast.com Subscribe and find previous episodes at: Apple Podcasts Spotify Stitcher   Follow us on Facebook & Instagram Buy a T-Shirt! Contact us at guitarspeakpodcast@gmail.com

It's another Potluck! In this episode, Scott and Wes answer your questions about privacy policies, coding for kids, MongaDB hosting, cloud backups, system design, #NoMoreFoo, and much more! Prismic - Sponsor Prismic is a Headless CMS that makes it easy to build website pages as a set of components. Break pages into sections of components using React, Vue, or whatever you like. Make corresponding Slices in Prismic. Start building pages dynamically in minutes. Get started at prismic.io/syntax. Sentry - Sponsor If you want to know what's happening with your code, track errors and monitor performance with Sentry. Sentry's Application Monitoring platform helps developers see performance issues, fix errors faster, and optimize their code health. Cut your time on error resolution from hours to minutes. It works with any language and integrates with dozens of other services. Syntax listeners new to Sentry can get two months for free by visiting Sentry.io and using the coupon code TASTYTREAT during sign up. Cloudinary - Sponsor Cloudinary is the best way to manage images and videos in the cloud. Edit and transform for any use case, from performance to personalization, using Cloudinary's APIs, SDKs, widgets, and integrations. Show Notes 04:49 - Ben Lamers: Heyo Scott and Wes! I am building a web app currently with my brother, and I was wondering when we get to launch it how do you go about correctly writing/adding Terms of Use and Privacy Policy. I'm assuming this may be quite different depending on the platform so maybe general resources or tips for this. Thanks! 06:45 - Fumbles O'Brian: Do you have any recommendations for teaching young children how to code? I have a 5-year-old niece in kindergarten who is absolutely fascinated watching me work, and I'd like to start teaching her basic concepts when she's able to read/write better. For example, she loves watching me make UI changes in React, it blows her mind that changing letters on one screen changes what a website looks like. 11:01 - Kenny: Gentlemen! Love this show and the content you put out. It keeps me occupied during my 5 and 6 mile runs. Thank you both for working so hard to keep it active, I know it takes a lot of work. I'm curious what you think about hosting your own MongoDB server? I'm relatively new to Mongo but want to start working with it for smaller projects. I've used MySQL for a decade, hosted online with shared hosting. Worked well for my relational db needs. Should I host my own Mongo when I'm ready for production, or pay the reasonable costs for something like Linode or maybe even Atlas? I have experience in Linux (enough to get by) and have my own virtualization cluster that I can spin up a server in seconds, along with an enterprise level firewall for managing traffic to and from. I actually just spun up a docker server this week and have a Mongo container running on it, though it's not accessible outside my network. This is purely for my development environments. Despite the firewall, my concern is security. Is it worth paying for a trusted solution like Linode, or should I put a little time in locking down my own Mongo container for my own use? Thank you both! Keep up the great work. 14:42 - Mike: Not a question but more of a rant… It's 2021, almost 2022, can we all stop using ‘foo' and ‘bar' and ‘baz' when teaching a programming concept? I applaud both of you because I don't recall seeing any of your content ever using such atrocious terms, however, I'm sad to see other prominent educators in the web development community use these terms from time to time. I feel like there are so many better examples that we could use to explain a concept and the use of ‘foo' is just confusing to beginners. That's all, just wanted to get that off my chest. Thanks for a wonderful podcast! #nomorefoo 18:53 - Amir: Hey Wes and Scott, thank you for your awesome podcast. What are the best cities in Canada and USA to get (more quantity, highest-paying) developer jobs? 23:44 - LW: Hi guys, I am finally starting to get into GraphQL and I don't get it. Specifically I am working to convert an existing REST API to GraphQL. This seems really tough and there is not much guidance out there on how to do it. The main part I am unsure of is how to write resolvers. If I use the existing query then GraphQL just seems like an over-engineered filter method. If I write an individual resolver for each column in the table - that's gonna be 100s of resolvers and super annoying to write. Have either of you ever moved something from REST to GraphQL? And, if so, how did you handle this? 27:57 - Dan: How does someone learn and actually practice using these system design topics like load balancing, caching, and database sharding. I have never had the need to use some of these things in my day-to-day work, but recently been interviewing and in the system design portion of the interview I feel a little lost. I've read about these topics and watched videos but haven't really seen how to implement these things. Any good resource recommendations? 31:57 - Matt: How do you know if you can trust an NPM package, from an unknown developer, that does not have many GitHub stars and has relatively few downloads? (The repo that made me ask this question is https://github.com/Wondermarin/react-color-palette). NPM audit automatically runs when you install a package, do any of you ever use additional security checks? 38:32 - Yosef: Hi I'm a beginner front-end developer and I heard you saying that being able to copy prototypes is a valuable skill, so I found some Figma free template and I copied them, the question is can I put them in my portfolio or deploy them? 40:00 - Nick: Hey dudes! I picked up a freelance project to make a brochure-style website and found myself having trouble to decide on what tools to pick for this site. I wanted to ask you and get your take, what tools/tech would you use to build a brochure site? By this, I mean the site should have mainly company information that is ideally editable by the stakeholders and has a contact form. Thanks! 44:22 - Casey: Hi Scooter and Wild Wes! Why do I feel so dirty when I'm forced to use negative values in CSS? 45:45 - Gnommer: Do you use some cloud sync service to backup your directory with projects? I mean OneDrive, Dropbox etc. I tried to use it alongside with Git, and it just messed my files so badly. On the other side I feel very uncomfortable without any backup apart from Github. BTW, according to last Potluck: polish ‘ł/Ł' is pronounced like ‘w' in ‘what a sick podcast you have'. Best from Poland ;) Links https://www.ryzerobotics.com/tello https://www.mongodb.com/cloud/atlas https://snyk.io/ https://deno.land/ https://kit.svelte.dev/ https://astro.build/ https://www.gatsbyjs.com/ https://www.dropbox.com/ https://www.backblaze.com/ https://www.synology.com/ https://support.apple.com/en-us/HT201250 ××× SIIIIICK ××× PIIIICKS ××× Scott: The Way Down Wes: Wooster Shortcut Shameless Plugs Scott: Modern GraphQL with Prisma - Sign up for the year and save 25%! Wes: All Courses - Use the coupon code ‘Syntax' for $10 off! Tweet us your tasty treats! Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

About NickNick Heudecker leads market strategy and competitive intelligence at Cribl, the observability pipeline company. Prior to Cribl, Nick spent eight years as an industry analyst at Gartner, covering data and analytics. Before that, he led engineering and product teams at multiple startups, with a bias towards open source software and adoption, and served as a cryptologist in the US Navy. Join Corey and Nick as they discuss the differences between observability and monitoring, why organizations struggle to get value from observability data, why observability requires new data management approaches, how observability pipelines are creating opportunities for SRE and SecOps teams, the balance between budgets and insight, why goats are the world's best mammal, and more.Links: Cribl: https://cribl.io/ Cribl Community: https://cribl.io/community Twitter: https://twitter.com/nheudecker Try Cribl hosted solution: https://cribl.cloud 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 Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It's an awesome approach. I've used something similar for years. Check them out. But wait, there's more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It's awesome. If you don't do something like this, you're likely to find out that you've gotten breached, the hard way. Take a look at this. It's one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That's canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I'm a big fan of this. More from them in the coming weeks.Corey: This episode is sponsored in part by our friends at Jellyfish. So, you're sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That's why they created the Jellyfish Engineering Management Platform, but don't you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you're doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode is a bit fun because I'm joined by someone that I have a fair bit in common with. Sure, I moonlight sometimes as an analyst because I don't really seem to know what that means, and he spent significant amounts of time as a VP analyst at Gartner. But more importantly than that, a lot of the reason that I am the way that I am is that I spent almost a decade growing up in Maine, and in Maine, there's not a lot to do other than sit inside for the nine months of winter every year and develop personality problems.You've already seen what that looks like with me. Please welcome Nick Heudecker, who presumably will disprove that, but maybe not. He is currently a senior director of market strategy and competitive intelligence at Cribl. Nick, thanks for joining me.Nick: Thanks for having me. Excited to be here.Corey: So, let's start at the very beginning. I like playing with people's titles, and you certainly have a lofty one. ‘competitive intelligence' feels an awful lot like jeopardy. What am I missing?Nick: Well, I'm basically an internal analyst at the company. So, I spend a lot of time looking at the broader market, seeing what trends are happening out there; looking at what kind of thought leadership content that I can create to help people discover Cribl, get interested in the products and services that we offer. So, I'm mostly—you mentioned my time in Maine. I was a cryptologist in the Navy and I spent almost all of my time focused on what the bad guys do. And in this job, I focus on what our potential competitors do in the market. So, I'm very externally focused. Does that help? Does that explain it?Corey: No, it absolutely does. I mean, you folks have been sponsoring our nonsense for which we thank you, but the biggest problem that I have with telling the story of Cribl was that originally—initially it was, from my perspective, “What is this hokey nonsense?” And then I learned and got an answer and then finish the sentence with, “And where can I buy it?” Because it seems that the big competitive threat that you have is something crappy that some rando sysadmin has cobbled together. And I say that as the rando sysadmin, who has cobbled a lot of things like that together. And it's awful. I wasn't aware you folks had direct competitors.Nick: Today we don't. There's a couple that it might be emerging a little bit, but in general, no, it's mostly us, and that's what I analyze every day. Are there other emerging companies in the space? Are there open-source projects? But you're right, most of the things that we compete against are DIY today. Absolutely.Corey: In your previous role, which you were at for a very long time in tech terms—which in a lot of other cases is, “Okay, that doesn't seem that long,” but seven and a half years is a respectable stint at a company. And you were at Gartner doing a number of analyst-like activities. Let's start at the beginning because I assure you, I'm asking this purely for the audience and not because I don't know the answer myself, but what exactly is the purpose of an analyst firm, of which Gartner is the most broadly known and, follow up, why do companies care what Gartner thinks?Nick: Yeah. It's a good question, one that I answer a lot. So, what is the purpose of an analyst firm? The purpose of an analyst firm is to get impartial information about something, whether that is supply chain technology, big data tech, human resource management technologies. And it's often difficult if you're an end-user and you're interested in say, acquiring a new piece of technology, what really works well, what doesn't.And so the analyst firm because in the course of a given year, I would talk to nearly a thousand companies and both end-users and vendors as well as investors about what they're doing, what challenges they're having, and I would distill that down into 30-minute conversations with everyone else. And so we provided impartial information in aggregate to people who just wanted to help. And that's the purpose of an analyst firm. Your second question, why do people care? Well, I didn't get paid by vendors.I got paid by the company that I worked for, and so I got to be Tron; I fought for the users. And because I talk to so many different companies in different geographies, in different industries, and I share that information with my colleagues, they shared with me, we had a very robust understanding of what's actually happening in any technology market. And that's uncommon kind of insight to really have in any kind of industry. So, that's the purpose and that's why people care.Corey: It's easy from the engineering perspective that I used to inhabit to make fun of it. It's oh, it's purely justification when you're making a big decision, so if it goes sideways—because find me a technology project that doesn't eventually go sideways—I want to be able to make sure that I'm not the one that catches heat for it because Gartner said it was good. They have an amazing credibility story going on there, and I used to have that very dismissive perspective. But the more I started talking to folks who are Gartner customers themselves and some of the analyst-style things that I do with a variety of different companies, it's turned into, “No, no. They're after insight.”Because it turns out, from my perspective at least, the more that you are focused on building a product that solves a problem, you sort of lose touch with the broader market because the only people you're really talking to are either in your space or have already acknowledged and been right there and become your customer and have been jaded to see things from your point of view. Getting a more objective viewpoint from an impartial third party does have value.Nick: Absolutely. And I want you to succeed, I want you to be successful, I want to carry on a relationship with all the clients that I would speak with, and so one of the fun things I would always ask is, “Why are you asking me this question now?” Sometimes it would come in, they'd be very innocuous;, “Compare these databases,” or, “Compare these cloud services.” “Well, why are you asking?” And that's when you get to, kind of like, the psychology of it.“Oh, we just hired a new CIO and he or she hates vendor X, so we have to get rid of it.” “Well, all right. Let's figure out how we solve this problem for you.” And so it wasn't always just technology comparisons. Technology is easy, you write a check and you hope for the best.But when you're dealing with large teams and maybe a globally distributed company, it really comes down to culture, and personality, and all the harder factors. And so it was always—those were always the most fun and certainly the most challenging conversations to have.Corey: One challenge that I find in this space is—in my narrow niche of the world where I focus on AWS bills, where things are extraordinarily yes or no, black or white, binary choices—that I talked to companies, like during the pandemic, and they were super happy that, “Oh, yeah. Our infrastructure has auto-scaling and it works super well.” And I look at the bill and the spend graph over time is so flat you could basically play a game of pool on top of it. And I don't believe that I'm talking to people who are lying to me. I truly don't believe that people make that decision, but what they believe versus what is evidenced in reality are not necessarily congruent. How do you disambiguate from the stories that people want to tell about themselves? And what they're actually doing?Nick: You have to unpack it. I think you have to ask a series of questions to figure out what their motivation is. Who else is on the call, as well? I would sometimes drop into a phone call and there would be a dozen people on the line. Those inquiry calls would go the worst because everyone wants to stake a claim, everyone wants to be heard, no one's going to be honest with you or with anyone else on the call.So, you typically need to have a pretty personal conversation about what does this person want to accomplish, what does the company want to accomplish, and what are the factors that are pushing against what those things are? It's like a novel, right? You have a character, the character wants to achieve something, and there are multiple obstacles in that person's way. And so by act five, ideally everything wraps up and it's perfect. And so my job is to get the character out of the tree that is on fire and onto the beach where the person can relax.So, you have to unpack a lot of different questions and answers to figure out, well, are they telling me what their boss wants to hear or are they really looking for help? Sometimes you're successful, sometimes you're not. Not everyone does want to be open and honest. In other cases, you would have a team show up to a call with maybe a junior engineer and they really just want you to tell them that the junior engineer's architecture is not a good idea. And so you do a lot of couples therapy as well. I don't know if this is really answering the question for you, but there are no easy answers. And people are defensive, they have biases, companies overall are risk-averse. I think you know this.Corey: Oh, yeah.Nick: And so it can be difficult to get to the bottom of what their real motivation is.Corey: My approach has always been that if you want serious data, you go talk to Gartner. If you want [anec-data 00:09:48] and some understanding, well, maybe we can have that conversation, but they're empowering different decisions at different levels, and that's fine. To be clear, I do not consider Gartner to be a competitor to what I do in any respect. It turns out that I am not very good at drawing charts in varying shades of blue and positioning things just so with repeatable methodology, and they're not particularly good at having cartoon animals as their mascot that they put into ridiculous situations. We each have our portion of the universe, and that's working out reasonably well.Nick: Well, and there's also something to unpack there as well because I would say that people look at Gartner and they think they have a lot of data. To a certain degree they do, but a lot of it is not quantifiable data. If you look at a firm like IDC, they specialize in—like, they are a data house; that is what they do. And so their view of the world and how they advise their clients is different. So, even within analyst firms, there is differentiation in what approach they take, how consultative they might be with their clients, one versus another. So, there certainly are differences that you could find the more exposure you get into the industry.Corey: For a while, I've been making a recurring joke that Route 53—Amazon's managed DNS service—is in fact a database. And then at some point, I saw a post on Reddit where someone said, “Yeah, I see the joke and it's great, but why should I actually not do this?” At which point I had to jump in and say, “Okay, look. Jokes are all well and good, but as soon as people start taking me seriously, it's very much time to come clean.” Because I think that's the only ethical and responsible thing to do in this ecosystem.Similarly, there was another great joke once upon a time. It was an April Fool's Day prank, and Google put out a paper about this thing they called MapReduce. Hilarious prank that Yahoo fell for hook, line, and sinker, and wound up building Hadoop out of it and we're still paying the price for that, years later. You have a bit of a reputation from your time at Gartner as being—and I quote—“The man who killed Hadoop.” What happened there? What's the story? And I appreciate your finally making clear to the rest of us that it was, in fact, a joke. What happened there?Nick: Well, one of the pieces of research that Gartner puts out every year is this thing called a Hype Cycle. And we've all seen it, it looks like a roller coaster in profile; big mountain goes up really high and then comes down steeply, drops into a valley, and then—Corey: ‘the trough of disillusionment,' as I recall.Nick: Yes, my favorite. And then plateaus out. And one of the profiles on that curve was Hadoop distributions. And after years of taking inquiry calls, and writing documents, and speaking with everybody about what they were doing, we realized that this really isn't taking off like everyone thinks it is. Cluster sizes weren't getting bigger, people were having a lot of challenges with the complexity, people couldn't find skills to run it themselves if they wanted to.And then the cloud providers came in and said, “Well, we'll make a lot of this really simple for you, and we'll get rid of HDFS,” which is—was a good idea, but it didn't really scale well. I think that the challenge of having to acquire computers with compute storage and memory again, and again, and again, and again, just was not sustainable for the majority of enterprises. And so we flagged it as this will be obsolete before plateau. And at that point, we got a lot of hate mail, but it just seemed like the right decision to make, right? Once again, we're Tron; we fight for the users.And that seemed like the right advice and direction to provide to the end-users. And so didn't make a lot of friends, but I think I was long-term right about what happened in the Hadoop space. Certainly, some fragments of it are left over and we're still seeing—you know, Spark is going strong, there's a lot of Hive still around, but Hadoop as this amalgamation of open-source projects, I think is effectively dead.Corey: I sure hope you're right. I think it has a long tail like most things that are there. Legacy is the condescending engineering term for ‘it makes money.' You were at Gartner for almost eight years and then you left to go work at Cribl. What triggered that? What was it that made you decide, “This is great. I've been here a long time. I've obviously made it work for me. I'm going to go work at a startup that apparently, even though it recently raised a $200 million funding round”—congratulations on that, by the way—“It still apparently can't afford to buy a vowel in its name.” That's C-R-I-B-L because, of course, it is. Maybe another consonant, while you're shopping. But okay, great. It's oddly spelled, it is hard to explain in some cases, to folks who are not already feeling pain in that space. What was it that made you decide to sit up and, “All right, this is where I want to be?”Nick: Well, I met the co-founders when I was an analyst. They were working at Splunk and oddly enough—this is going to be an interesting transition compared to the previous thing we talked about—they were working on Hunk, which was, let's use HDFS to store Splunk data. Made a lot of sense, right? It could be much more cost-effective than high-cost infrastructure for Splunk. And so they told me about this; I was interested.And so I met the co-founders and then I reconnected with them after they left and formed Cribl. And I thought the story was really cool because where they're sitting is between sources and destinations of observability data. And they were solving a problem that all of my customers had, but they couldn't resolve. They would try and build it themselves. They would look at—Kafka was a popular choice, but that had some challenges for observability data—works fantastically well for application data.And they were just—had a very pragmatic view of the world that they were inhabiting and the problem that they were looking to solve. And it looked kind of like a no-brainer of a problem to solve. But when you double-click on it, when you really look down and say, “All right, what are the challenges with doing this?” They're really insurmountable for a lot of organizations. So, even though they may try and take a DIY approach, they often run into trouble after just a few weeks because of all the protocols you have to support, all the different data formats, and all the destinations, and role-based access control, and everything else that goes along with it.And so I really liked the team. I thought the product inhabited a unique space in the market—we've already talked about the lack of competitors in the space—and I just felt like the company was on a rocket ship—or is a rocket ship—that basically had unbounded success potential. And so when the opportunity arose to join the team and do a lot of the things I like doing as an analyst—examining the market, talking to people looking at competitive aspects—I jumped at it.Corey: It's nice when you see those opportunities that show up in front of you, and the stars sort of align. It's like, this is not just something that I'm excited about and enthused about, but hey, they can use me. I can add something to where they're going and help them get there better, faster, sooner, et cetera, et cetera.Nick: When you're an analyst, you look at dozens of companies a month and I'd never seen an opportunity that looked like that. Everything kind of looked the same. There's a bunch of data integration companies, there's a bunch of companies with Spark and things like that, but this company was unique; the product was unique, and no one was really recognizing the opportunity. So, it was just a great set of things that all happen at the same time.Corey: It's always fun to see stars align like that. So—Nick: Yeah.Corey: —help me understand in a way that can be articulated to folks who don't have 15 years of grumpy sysadmin experience under their belts, what does Cribl do?Nick: So, Cribl does a couple of things. Our flagship product is called LogStream, and the easiest way to describe that is as an abstraction between sources and destinations of data. And that doesn't sound very interesting, but if you, from your sysadmin background, you're always dealing with events, logs, now there's traces, metrics are also hanging around—Corey: Oh, and of course, the time is never synchronized with anything either, so it's sort of a giant whodunit, mystery, where half the eyewitnesses lie.Nick: Well, there's that. There's a lot of data silos. If you got an agent deployed on a system, it's only going to talk to one destination platform. And you repeat this, maybe a dozen times per server, and you might have 100,000 or 200,000 servers, with all of these different agents running on it, each one locked into one destination. So, you might want to be able to mix and match that data; you can't. You're locked in.One of the things LogStream does is it lets you do that exact mixing and matching. Another thing that this product does, that LogStream does, is it gives you ability to manage that data. And then what I mean by that is, you may want to reduce how much stuff you're sending into a given platform because maybe that platform charges you by your daily ingest rates or some other kind of event-based charges. And so not all that data is valuable, so why pay to store it if it's not going to be valuable? Just dump it or reduce the amount of volume that you've got in that payload, like a Windows XML log.And so that's another aspect that it allows you to do, better management of that stuff. You can redact sensitive fields, you can enrich the data with maybe, say, GeoIPs so you know what kind of data privacy laws you fall under and so on. And so, the story has always been, land the data in your destination platform first, then do all those things. Well, of course, because that's how they charge you; they charge you based on daily ingest. And so now the story is, make those decisions upfront in one place without having to spread this logic all over, and then send the data where you want it to go.So, that's really, that's the core product today, LogStream. We call ourselves an observability pipeline for observability data. The other thing we've got going on is this project called AppScope, and I think this is pretty cool. AppScope is a black box instrumentation tool that basically resides between the application runtime and the kernel and any shared libraries. And so it provides—without you having to go back and instrument code—it instruments the application for you based on every call that it makes and then can send that data through something like LogStream or to another destination.So, you don't have to go back and say, “Well, I'm going to try and find the source code for this 30-year old c++ application.” I can simply run AppScope against the process, and find out exactly what that application is doing for me, and then relay that information to some other destination.Corey: This episode is sponsored in part by Liquibase. If you're anything like me, you've screwed up the database part of a deployment so severely that you've been banned from touching every anything that remotely sounds like SQL, at at least three different companies. We've mostly got code deployments solved for, but when it comes to databases we basically rely on desperate hope, with a roll back plan of keeping our resumes up to date. It doesn't have to be that way. Meet Liquibase. It is both an open source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails to ensure you'll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at liquibase.com. Offer does not apply to Route 53.Corey: I have to ask because I love what you're doing, don't get me wrong. The counterargument that always comes up in this type of conversation is, “Who in their right mind looks at the state of the industry today and says, ‘You know what we need? That's right; another observability tool.'” what differentiates what you folks are building from a lot of the existing names in the space? And to be clear, a lot of the existing names in the space are treating observability simply as hipster monitoring. I'm not entirely sure they're wrong, but that's a different fight for a different time.Nick: Yeah. I'm happy to come back and talk about that aspect of it, too. What's different about what we're doing is we don't care where the data goes. We don't have a dog in that fight. We want you to have better control over where it goes and what kind of shape it's in when it gets there.And so I'll give an example. One of our customers wanted to deploy a new SIEM—Security Information Event Management—tool. But they didn't want to have to deploy a couple hundred-thousand new agents to go along with it. They already had the data coming in from another agent, they just couldn't get the data to it. So, they use LogStream to send that data to their new desired platform.Worked great. They were able to go from zero to a brand new platform in just a couple days, versus fighting with rolling out agents and having to update them. Did they conflict with existing agents? How much performance did it impact on the servers, and so on? So, we don't care about the destination. We like everybody. We're agnostic when it comes to where that data goes. And—Corey: Oh, it's not about the destination. It's about the journey. Everyone's been saying it, but you've turned it into a product.Nick: It's very spiritual. So, we [laugh] send, we send your observability data on a spiritual [laugh] journey to its destination, and we can do quite a bit with it on the way.Corey: So, you said you offered to go back as well and visit the, “Oh, it's monitoring, but we're going to call it observability because otherwise we get yelled out on Twitter by Charity Majors.” How do you view that?Nick: Monitoring is the things you already know. Right? You know what questions you want to ask, you get an alert if something goes out of bounds or something goes from green to red. Think about monitoring as a data warehouse. You shape your data, you get it all in just the right condition so you can ask the same question over and over again, over different time domains.That's how I think about monitoring. It's prepackaged, you know exactly what you want to do with it. Observability is more like a data lake. I have no idea what I'm going to do with this stuff. I think there's going to be some signals in here that I can use, and I'm going to go explore that data.So, if monitoring is your known knowns, observability is your unknown unknowns. So, an ideal observability solution gives you an opportunity to discover what those are. Once you discover them. Great. Now, you can talk about how to get them into your monitoring system. So, for me, it's kind of a process of discovery.Corey: Which makes an awful lot of sense. The problem I've always had with the monitoring approach is it falls into this terrible pattern of enumerate the badness. In other words, “Imagine all the ways that this system can fail,” and then build an alerting that lets you know when any of those things happen. And what happens next is inevitable to anyone who's ever dealt with the tricksy devils known as computers, and what happens, of course, is that they find new ways to fail and you generally get to add to the list of things to check for, usually at two o'clock in the morning.Nick: On a Sunday.Corey: Oh, absolutely. It almost doesn't matter when. The real problem is when these things happen, it's, “What day, actually, is it?” And you have to check the calendar to figure out because your third time that week being woken up in the dead of night. It's like an infant but less than endearing.So, that has been the old school approach, and there's unfortunately still an awful lot of, we'll just call it nonsense, in the industry that still does exactly the same thing, except now they call it observability because—hearkening back to earlier in our conversation—there's a certain point in the Gartner Hype Cycle that we are all existing within. What's the deal with that?Nick: Well, I think that there are a lot of entrenched interests in the monitoring space. And so I think you always see this when a new term comes around. Vendors will say, “All right, well, there's a lot of confusion about this. Let me back-fit my product into this term so that I can continue to look like I'm on the leading edge and I'm not going to put any of my revenues in jeopardy.” I know, that's a cynical view, but I've seen it over and over again.And I think that's unfortunate because there's a real opportunity to have a better understanding of your systems, to better understand what's happening in all the containers you're deploying and not tearing down the way that you should, to better understand what's happening in distributed systems. And it's going to be a real missed opportunity if that is what happens. If we just call this ‘Monitoring 2.0' it's going to leave a lot of unrealized potential in the market.Corey: The big problem that I've seen in a lot of different areas is—I'll be direct—consolidation where you have a company that starts to do a thing—and that's great—and then they start doing other things that are tied to it. And in turn, they start, I guess, gathering everything in the ecosystem. If you break down observability into various constituent parts, I—know, I know, the pillars thing is going to upset people; ignore that for now—and if you have an offering that's weak in a particular area, okay, instead of building it organically into the product, or saying, “Yeah, that's not what we do,” there's an instinct to acquire a company or build that functionality out. And it turns out that we're building what feels the lot to me like the SaaS equivalent of multifunction printers: they can print, they can scan, they can fax, and none of those three very well, so it winds up with something that dissatisfies everyone, rather than a best-of-breed solution that has a very clear and narrow starting and stopping point. How do you view that?Nick: Well, what you've described is a compromise, right? A compromise is everyone can work and no one's happy. And I think that's the advantage of where LogStream comes in. The reality is best-of-breed. Most enterprises today have 30 or more different monitoring tools—call them observability tools if you want to—and you will never pry those tools from the dead hands of those sysadmins, DevOps engineers, SREs, et cetera.They all integrate those tools into how they work and their processes. So, we're living in a best-of-breed world. It's like that in data and analytics—my former beat—and it's like that in monitoring and observability. People really gravitate towards the tools they like, they gravitate towards the tools their friends are using. And so you need a way to be able to mix and match that stuff.And just because I want to stay [laugh] on message, that's really where the LogStream story kind of blends in because we do that; we allow you to mix and match all those different pieces.Corey: Joke's on you. I use Nagios and I have no friends. I'm not convinced those two things are entirely unrelated, but here we are. So here's, I guess, the big burning question that a lot of folks—certainly not me, but other undefined folks, ‘lots of people are saying'—so you built something interesting that actually works. I want to be clear on this.I have spoken to customers of yours. They swear by it instead of swearing at it, which happens with other companies. Awesome. You have traction, you're moving forward, things are going great. Here's $200 million is the next part of that story, and on some level, my immediate reaction—which does need updating, let's be clear here—is like, all right.I'm trying to build a product. I can see how I could spend a few million bucks. “Well, what can you do with I don't know, 100 times that?” My easy answer is, “Something monstrous.” I don't believe that is the case here. What is the growth plan? What are you doing that makes having that kind of a war chest a useful and valuable thing to have?Nick: Well, if you speak with the co-founders—and they've been open about this—we view ourselves as a generational company. We're not just building one product. We've been thinking about, how do we deliver on observability as this idea of discovery? What does that take? And it doesn't mean that we're going to be less agnostic to other destinations, we still think there's an incredible amount of value there and that's not going away, but we think there's maybe an interim step that we build out, potentially this idea of an observability data lake where you can explore these environments.Certainly, there's other types of options in the space today. Most of them are SQL-based, which is interesting because the audience that uses monitoring and observability tools couldn't care less about SQL right? They want search, they want regex, and so you've got to have the right tool for that audience. And so we're thinking about what that looks like going forward. We're doubling down on people.Surprisingly, this is a very—like anything else in software, it is people-intensive. And so certainly those are other aspects that we're exploring with the recent investment, but definitely, multiproduct company is our future and continued expansion.Corey: Expansion is always a fun one. It's the idea of, great, are you looking at going deeper into the areas you're already active within, or is it more of a, “Ah, so we've solved the, effectively, log routing problem. That's great. Let's solve other problems, too.” Or is it more of a, I guess, a doubling down and focusing on what's working? And again, that probably sounds judgmental in a way I don't intend it to at all. I just have a hard time contextualizing that level of scale coming from a small company perspective the way that I do.Nick: Yeah. Our plan is to focus more intently on the areas that we're in. We have a huge basis of experience there. We don't want to be all things to all people; that dilutes the message down to nothing, so we want to be very specific in the audiences we talk to, the problems we're trying to solve, and how we try to solve them.Corey: The problem I've always found with a lot of the acquisition, growth thrashing of—let me call it what I think it is: companies in decline trying to strain relevancy, it feels almost like a, “We don't see a growth strategy. So, we're going to try and acquire everything that hold still long enough, at some level, trying to add more revenue to the pile, but also thrashing in the sense of, okay. They're going to teach us how to do things in creative, awesome ways,” but it never works out that way. When you have a 50,000 person company acquiring a 200 person company, invariably the bigger culture is going to dominate. And I don't understand why that mistake seems to continually happen again, and again, and again.And people think I'm effectively alluding to—or whenever the spoken word version of subtweeting is—a particular company or a particular acquisition. I'm absolutely not, there are probably 50 different companies listening right now who thinks, “Oh, God. He's talking about us.” It's the common repeating trend. What is that?Nick: It's hard to say. In some cases, these acquisitions might just be talent. “We need to know how to do X. They know how to do X. Let's do it.” They may have very unique niche technology or software that another company thinks they can more broadly apply.Also, some of these big companies, these may not be board-level or CEO-level decisions. A business unit might decide, “Oh, I like what that company is doing. I'm going to go acquire it.” And so it looks like MegaCorp bought TinyCorp, but it's really, this tiny business unit within MegaCorp bought tiny company. The reality is often different from what it looks like on the outside.So, that's one way. Another is, you know, if they're going to teach us to be more effective with tech or something like that, you're never going to beat culture. You're never going to be the existing culture. If it's 50,000, against 200, obviously we know who wins there. And so I don't know if that's realistic.I don't know if the big companies are genuine when they say that, but it could just be the messaging that they use to make people happy and hopefully retain as many of those new employees for as long as they can. Does that make sense?Corey: No, it makes perfect sense. It's the right answer. It does articulate what is happening there, and I think I keep falling prey to the same failure. And it's hard. It's pernicious, but companies are not monolithic entities.There's no one person at all of these companies each who is making these giant unilateral decisions. It's always some product manager or some particular person who has a vision and a strategy in the department. It is not something that the company board is agreeing on every little decision that gets made. They're distributed entities in many respects.Nick: Absolutely. And that's only getting more pervasive as companies get larger [laugh] through acquisition. So, you're going to see more and more of that, and so it's going to look like we're going to put one label on it, one brand. Often, I think internally, that's the exact opposite of what actually happened, how that decision got made.Corey: Nick, I want to thank you for taking so much time to speak with me about what you're up to over there, how your path has shaped, how you view the world, and also what Cribl does these days. If people want to learn more about what you're up to, how you think about the world, or even possibly going to work at Cribl which, having spoken to a number of people over there, I would endorse it. How do they find you?Nick: Best place to find us is by joining our community: cribl.io/community, and Cribl is spelled C-R-I-B-L. You can certainly reach out there, we've got about 2300 people in our community Slack, so it's a great group. You can also reach out to me on Twitter, I'm @nheudecker, N-H-E-U-D-E-C-K-E-R. Tell me what you thought of the episode; love to hear it. And then beyond that, you can also sign up for our free cloud tier at cribl.cloud. It's a pretty generous one terabyte a day processing, so you can start to send data in and send it wherever you'd like to be.Corey: To be clear, this free as in beer, not free as an AWS free tier?Nick: This is free as in beer.Corey: Excellent. Excellent.Nick: I think I'm getting that right. I think it's free as in beer. And the other thing you can try is our hosted solution on AWS, fully managed cloud at cribl.cloud, we offer a free one terabyte per day processing, so you can start to send data into that environment and send it wherever you'd like to go, in whatever shape that data needs to be in when it gets there.Corey: And we will, of course, put links to that in the [show notes 00:35:21]. Thank you so much for your time today. I really appreciate it.Nick: No, thank you for having me. This was a lot of fun.Corey: Nick Heudecker, senior director, market strategy and competitive intelligence at Cribl. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment explaining that the only real reason a startup should raise a $200 million funding round is to pay that month's AWS bill.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Johannes Schindelin is the maintainer (BDFL) of Git for Windows.Apple Podcasts | Spotify | Google PodcastsGit is a fundamental piece of the software community, and we get to learn the history and inner workings of the project in this episode. Maintaining a widely-used open source project involves a ton of expected complexity around handling bug reports, deprecations, and inclusive culture, but also requires management of inter-personal relationships, ease of contribution, and other aspects that are fascinating to learn about.Highlights00:06 - How did Johannes end up as the maintainer of Git for Windows?06:30 - The Git community in the early days. Fun fact: Git used to be called `dircache`08:30 - How many downloads does Git for Windows get today?10:15 - Why does Git for Windows a separate project? Why not make improvements to Git itself?24:00 - How do you deprecate functionality when there are millions of users of your product and you have no telemetry?30:00 - What does being the BDFL of a project mean? What does Johannes day-to-day look like?33:00 - What is GitGitGadget? How does it make contributions easier?41:00 - How do foster an inclusive community of an open-source project?50:00 - What’s next for Git? Get on the email list at www.softwareatscale.dev

This week, the JavaScript Jabber panel discusses the various "Creeds of Craftsmanship" from the programming languages out there. They discuss the different principles and the unifying concepts they all have alongside the ethos of what makes each language's approach to programming unique. Panel AJ O'NealCharles Max WoodSteve Edwards Sponsors Dev Influencers AcceleratorRaygun | Click here to get started on your free 14-day trialLevel Up | Devchat.tv Picks AJ- Creeds of CraftsmanshipAJ- Zeskit HDMI CouplerAJ- Zeskit 10ft HDMCharles- PodcastBootcamp.ioCharles- JavaScript PicksCharles- Masters of DoomCharles- How to Make Sh*t HappenCharles- The Road Back to YouCharles- Leviathan Wakes  Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode )coolaj86- Twitch Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv )

This week, the JavaScript Jabber panel discusses the various "Creeds of Craftsmanship" from the programming languages out there. They discuss the different principles and the unifying concepts they all have alongside the ethos of what makes each language's approach to programming unique. Panel AJ O'NealCharles Max WoodSteve Edwards Sponsors Dev Influencers AcceleratorRaygun | Click here to get started on your free 14-day trialLevel Up | Devchat.tv Picks AJ- Creeds of CraftsmanshipAJ- Zeskit HDMI CouplerAJ- Zeskit 10ft HDMCharles- PodcastBootcamp.ioCharles- JavaScript PicksCharles- Masters of DoomCharles- How to Make Sh*t HappenCharles- The Road Back to YouCharles- Leviathan Wakes  Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode )coolaj86- Twitch Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv )

Did you know there is a thriving community of podcasters in the Long Island area of NY? One of the leaders in that community is entrepreneur, web developer, musician, and podcaster Bruce Chamoff. Rich had the pleasure of connecting with Bruce through the NY City Podcast Network and the New York and Long Island Podcast LinkedIn Group. Bruce also invited Rich to speak at the PodKnow 2021 Podcast Conference this past June alongside a panel of well-known podcasters and podcast luminaries in the space. When not running events or running his many podcasting communities, Bruce can be heard on his podcast Becoming A Successful Podcaster providing tips, insights, and guidance for new and established podcasters. Bruce is also known for his public speaking throughout the US and Canada for podcasting and WordPress. ALERT!!: New episodes of Toys & Tech of the Trade will be released on Saturdays from now on. The views expressed on air during Toys & Tech of the Trade do not represent the views of the RAGE Works staff, partners, or affiliates. Listener discretion advised. Toys, Tech, Awesome People, Stuff, and Services Mentioned in This Episode Disclaimer: Some of these links are affiliate links, which means that if you click and make a purchase via the link, RAGE Works will receive a small commission. Samson USB Mic: https://amzn.to/3BRoDpcChris Brogan: https://chrisbrogan.com/Magix: https://www.magix.com/us/Filezilla FTP: https://filezilla-project.org/Git: https://git-scm.com/Roku: https://amzn.to/3aNmVcNTascam 32 Track Recorder: https://amzn.to/3BRp56SPodcasting: Do-It-Yourself Guide by Todd Cochrane: https://amzn.to/3FXrtMa Guest Links Listen To Becoming A Successful Podcaster with Bruce Chamoff: https://podcasts.apple.com/us/podcast/be-a-successful-podcaster-with-bruce-chamoff/id1553846808Connect with Bruce on LinkedIn: https://www.linkedin.com/in/brucecebdesign/Follow Bruce on Twitter: https://twitter.com/brucechamoffFollow Bruce on Instagram: https://www.instagram.com/bruce_chamoff/Listen to Bruce's music on Spotify: https://open.spotify.com/artist/4lZgvTWEAkTnPQbtvNUctm?si=Jf9R-JlxTduxgbOHJZwMQwVisit the NY City Podcast Network: https://nycpodcastnetwork.com/ Keep up with RAGE Works Instagram: https://www.instagram.com/rageworks/Twitter: https://twitter.com/RAGE_WorksFacebook: https://www.facebook.com/OfficialRAGEWorks/Subscribe to the RAGE Works Newsletter: https://sendfox.com/rageworks Check Out Some of the Other Shows on the RAGE Works Network Call Me When It's Over: https://www.rageworksnetwork.com/show/cmwio/Cheese! A Photography Podcast: https://www.rageworksnetwork.com/show/capp/Black is the New Black: https://www.rageworksnetwork.com/show/bitnb/The Variant Issue: https://www.rageworksnetwork.com/show/tvi/Turnbuckle Tabloid: https://www.rageworksnetwork.com/show/tbt/Trek Untold: https://www.rageworksnetwork.com/show/trek-untold/The Eat 4 Life Podcast: https://www.rageworksnetwork.com/show/eat4life/    

As we launch full steam into Phase 2 of Programming By Stealth, Bart Busschots introduces us to the Node Package Manager and Node itself. Unlike our mini-series within a series for Git and Chezmoi, Bart isn't going to do an exhaustive walk through NPM and Node. Instead he's going to teach use what we need as we go along. In order for that to make any sense at all, in this installment, he explain to us at a high level Node and NPM are, and what problems they solve. This lesson isn't all theory though, we actually get to use Node and NPM to build a tiny, self-contained JavaScript app. I had great fun in this installment and Bart's always fabulous tutorial shownotes are particularly well-written this time. You can find them over at pbs.bartificer.net/...

First record party. I'm back at it in the basement spinning up a couple hours of the good stuff. It's going to take a couple episodes to polish off the rough edges but starting it off right. Git... Real Punk Radio podcast Network brings you the best in Punk, Rock, Underground Music around! From Classic Oi!, Psychobilly and Hardcore to some Classic Rock n Roll and 90's indie Alt Rock greatness!! With Tons of Live DJ's that like to Talk Music From Garage Rock, to Ska.. We are True MUSIC GEEKS!

Niall Crosby, creator of AgGrid, joins the panel to discuss the journey from building an open source data grid used all over the world to providing support and enterprise features and running a successful business based on that same open source software. Panel AJ O'NealCharles Max WoodDan ShappirSteve Edwards Guest Niall Crosby Sponsors JavaScript Error and Performance Monitoring | SentryPodcastBootcamp.ioLevel Up | Devchat.tv Links React Data Grid: React UIWhy The World Needed Another Angular GridGitHub | coolaj86/ajquery.jsAG GridTwitter: AG Grid ( @ag_grid ) Picks AJ- GitHub | BeyondCodeBootcamp/jsdoc-typescript-starterAJ- GitHub | coolaj86/node-docker-seedAJ- GitHub | ewjoachim/zen-of-pythonAJ- GitHub | BeyondCodeBootcamp/go-proverbsAJ- GitHub | coolaj86/ajquery.jsCharles- Ready Player TwoCharles- Masters of DoomCharles- JavaScript PicksDan- "You Don't Know JS Yet" second edition booksDan- The White Lotus Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact Dan: GitHub: Dan Shappir ( DanShappir )LinkedIn: Dan ShappirTwitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards Special Guest: Niall Crosby.

Niall Crosby, creator of AgGrid, joins the panel to discuss the journey from building an open source data grid used all over the world to providing support and enterprise features and running a successful business based on that same open source software. Panel AJ O'NealCharles Max WoodDan ShappirSteve Edwards Guest Niall Crosby Sponsors JavaScript Error and Performance Monitoring | SentryPodcastBootcamp.ioLevel Up | Devchat.tv Links React Data Grid: React UIWhy The World Needed Another Angular GridGitHub | coolaj86/ajquery.jsAG GridTwitter: AG Grid ( @ag_grid ) Picks AJ- GitHub | BeyondCodeBootcamp/jsdoc-typescript-starterAJ- GitHub | coolaj86/node-docker-seedAJ- GitHub | ewjoachim/zen-of-pythonAJ- GitHub | BeyondCodeBootcamp/go-proverbsAJ- GitHub | coolaj86/ajquery.jsCharles- Ready Player TwoCharles- Masters of DoomCharles- JavaScript PicksDan- "You Don't Know JS Yet" second edition booksDan- The White Lotus Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact Dan: GitHub: Dan Shappir ( DanShappir )LinkedIn: Dan ShappirTwitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards Special Guest: Niall Crosby.

About EmmaEmma Bostian is a Software Engineer at Spotify in Stockholm. She is also a co-host of the Ladybug Podcast, author of Decoding The Technical Interview Process, and an instructor at LinkedIn Learning and Frontend Masters.Links: Ladybug Podcast: https://www.ladybug.dev LinkedIn Learning: https://www.linkedin.com/learning/instructors/emma-bostian Frontend Masters: https://frontendmasters.com/teachers/emma-bostian/ Decoding the Technical Interview Process: https://technicalinterviews.dev Twitter: https://twitter.com/emmabostian 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 Jellyfish. So, you're sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That's why they created the Jellyfish Engineering Management Platform, but don't you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you're doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part.Corey: This episode is sponsored in part by Liquibase. If you're anything like me, you've screwed up the database part of a deployment so severely that you've been banned from touching every anything that remotely sounds like SQL, at at least three different companies. We've mostly got code deployments solved for, but when it comes to databases we basically rely on desperate hope, with a roll back plan of keeping our resumes up to date. It doesn't have to be that way. Meet Liquibase. It is both an open source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails to ensure you'll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at liquibase.com. Offer does not apply to Route 53.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the weird things that I've found in the course of, well, the last five years or so is that I went from absolute obscurity to everyone thinking that I know everyone else because I have thoughts and opinions on Twitter. Today, my guest also has thoughts and opinions on Twitter. The difference is that what she has to say is actually helpful to people. My guest is Emma Bostian, software engineer at Spotify, which is probably, if we can be honest about it, one of the least interesting things about you. Thanks for joining me.Emma: Thanks for having me. That was quite the intro. I loved it.Corey: I do my best and I never prepare them, which is a blessing and a curse. When ADHD is how you go through life and you suck at preparation, you've got to be good at improv. So, you're a co-host of the Ladybug Podcast. Let's start there. What is that podcast? And what's it about?Emma: So, that podcast is just my three friends and I chatting about career and technology. We all come from different backgrounds, have different journeys into tech. I went the quote-unquote, “Traditional” computer science degree route, but Ali is self-taught and works for AWS, and Kelly she has, like, a master's in psychology and human public health and runs her own company. And then Sydney is an awesome developer looking for her next role. So, we all come from different places and we just chat about career in tech.Corey: You're also an instructor at LinkedIn Learning and Frontend Masters. I'm going to guess just based upon the name that you are something of a frontend person, which is a skill set that has constantly eluded me for 20 years, as given evidence by every time I've tried to build something that even remotely touches frontend or JavaScript in any sense.Emma: Yeah, to my dad's disdain, I have stuck with the frontend; he really wanted me to stay backend. I did an internship at IBM in Python, and you know, I learned all about assembly language and database, but frontend is what really captures my heart.Corey: There's an entire school of thought out there from a constituency of Twitter that I will generously refer to as shitheads that believe, “Oh, frontend is easy and it's somehow less than.” And I would challenge anyone who holds that perspective to wind up building an interface that doesn't look like crap first, then come and talk to me. Spoiler, you will not say that after attempting to go down that rabbit hole. If you disagree with this, you can go ahead and yell at me on Twitter so I know where you're hiding, so I can block you. Now, that's all well and good, but one of the most interesting things that you've done that aligns with topics near and dear to my heart is you wrote a book.Now, that's not what's near and dear to my heart; I have the attention span to write a tweet most days. But the book was called Decoding the Technical Interview Process. Technical interviewing is one of those weird things that comes up from time to time, here and everywhere else because it's sort of this stylized ritual where we evaluate people on a number of skills that generally don't reflect in their day-to-day; it's really only a series of skills that you get better by practicing, and you only really get to practice them when you're interviewing for other jobs. That's been my philosophy, but again, I've written a tweet on this; you've written a book. What's the book about and what drove you to write it?Emma: So, the book covers everything from an overview of the interview process, to how do you negotiate a job offer, to systems design, and talks about load balancing and cache partitioning, it talks about what skills you need from the frontend side of things to do well on your JavaScript interviews. I will say this, I don't teach HTML, CSS, and JavaScript in-depth in the book because there are plenty of other resources for that. And some guy got mad at me about that the other day and wanted a refund because I didn't teach the skills, but I don't need to. [laugh]. And then it covers data structures and algorithms.They're all written in JavaScript, they have easy to comprehend diagrams. What drove me to write this is that I had just accepted a job offer in Stockholm for a web developer position at Spotify. I had also just passed my Google technical interviews, and I finally realized, holy crap, maybe I do know what I'm doing in an interview now. And this was at the peak of when people were getting laid off due to COVID and I said, “You know what? I have a lot of knowledge. And if I have a computer science degree and I was able to get through some of the hardest technical interviews, I think I should share that with the community.”Because some people didn't go through a CS degree and don't understand what a linked list is. And that's not their fault. It's just unfortunately, there weren't a lot of great resources—especially for web developers out there—to learn these concepts. Cracking the Coding Interview is a great book, but it's written in backend language and it's a little bit hard to digest as a frontend developer. So, I decided to write my own.Corey: How much of the book is around the technical interview process as far as ask, “Here's how you wind up reversing linked lists,” or, “Inverting a binary tree,” or whatever it is where you're tracing things around without using a pointer, how do you wind up detecting a loop in a recursive whatever it is—yeah, as you can tell, I'm not a computer science person at all—versus how much of it is, effectively, interview 101 style skills for folks who are even in non-technical roles could absorb?Emma: My goal was, I wanted this to be approachable by anyone without extensive technical knowledge. So, it's very beginner-friendly. That being said, I cover the basic data structures, talking about what traditional methods you would see on them, how do you code that, what does that look like from a visual perspective with fake data? I don't necessarily talk about how do you reverse a binary tree, but I do talk about how do you balance it if you remove a node? What if it's not a leaf node? What if it has children? Things like that.It's about [sigh] I would say 60/40, where 40% is coding and technical stuff, but maybe—eh, it's a little bit closer to 50/50; it kind of depends. I do talk about the take-home assessment and tips for that. When I do a take-home assessment, I like to include a readme with things I would have done if I had more time, or these are performance trade-offs that I made; here's why. So, there's a lot of explanation as to how you can improve your chances at moving on to the next round. So yeah, I guess it's 50/50.I also include a section on tips for hiring managers, how to create an inclusive and comfortable environment for your candidates. But it's definitely geared towards candidates, and I would say it's about 50/50 coding tech and process stuff.Corey: One of the problems I've always had with this entire industry is it feels like we're one of the only industries that does this, where we bring people in, and oh, you've been an engineer for 15 years at a whole bunch of companies I've recognized, showing career progression, getting promoted at some of them transitioning from high-level role to high-level role. “Great, we are so glad that you came in to interview. Now, up to the whiteboard, please, and implement FizzBuzz because I have this working theory that you don't actually know how to code, and despite the fact that you've been able to fake your way through it at big companies for 15 years, I'm the one that's going to catch you out with some sort of weird trivia question.” It's this adversarial, almost condescending approach and I don't see it in any other discipline than tech. Is that just because I'm not well-traveled enough? Is that because I'm misunderstanding the purpose of all of these things? Or, what is this?Emma: I think partially it was a gatekeeping solution for a while, for people who are comfortable in their roles and may be threatened by people who have come through different paths to get to tech. Because software engineer used to be an accredited title that you needed a degree or certification to get. And in some countries it still is, so you'll see this debate sometimes about calling yourself a software engineer if you don't have that accreditation. But in this day and age, people go through boot camps, they can come from other industries, they can be self-taught. You don't need a computer science degree, and I think the interview process has not caught up with that.I will say [laugh] the worst interview I had was at IBM when I was already working there. I was already a web developer there, full-time. I was interviewing for a role, and I walked into the room and there were five guys sitting at a table and they were like, “Get up to the whiteboard.” It was for a web development job and they quizzed me about Java. And I was like, “Um, sir, I have not done Java since college.” And they were like, “We don't care.”Corey: Oh, yeah, coding on a whiteboard in front of five people who already know the answer—Emma: Horrifying.Corey: —during a—for them, it's any given Tuesday, and for you, it is a, this will potentially determine the course that your career takes from this point forward. There's a level of stress that goes into that never exists in our day-to-day of building things out.Emma: Well, I also think it's an artificial environment. And why, though? Like, why is this necessary? One of the best interviews I had was actually with Gatsby. It was for an open-source maintainer role, and they essentially let me try the product before I bought it.Like, they let me try out doing the job. It was a paid process, they didn't expect me to do it for free. I got to choose alternatives if I wanted to do one thing or another, answer one question or another, and this was such an exemplary process that I always bring it up because that is a modern interview process, when you are letting people try the position. Now granted, not everyone can do this, right? We've got parents, we've got people working two jobs, and not everyone can afford to take the time to try out a job.But who can also afford a five-stage interview process that still warrants taking vacation days? So, I think at least—at the very least—pay your candidates if you can.Corey: Oh, yeah. One of the best interviews I've ever had was at a company called Three Rings Design, which is now defunct, unfortunately, but it was fairly typical ops questions of, “Yeah, here's an AWS account. Spin up a couple EC2 instances, load balance between them, have another one monitored. You know, standard op stuff. And because we don't believe in asking people to work for free, we'll pay you $300 upon completion of the challenge.”Which, again, it's not huge money for doing stuff like that, but it's also, this shows a level of respect for my time. And instead of giving me a hard deadline of when it was due, they asked me, “When can we expect this by?” Which is a great question in its own right because it informs you about a candidate's ability to set realistic deadlines and then meet them, which is one of those useful work things. And they—unlike most other companies I spoke with in that era—were focused on making it as accommodating for the candidate as possible. They said, “We're welcome to interview you during the workday; we can also stay after hours and have a chat then, if that's more convenient for your work schedule.”Because they knew I was working somewhere else; an awful lot of candidates are. And they just bent over backwards to be as accommodating as possible. I see there's a lot of debate these days in various places about the proper way to interview candidates. No take-home because biases for people who don't have family obligations or other commitments outside of work hours. “Okay, great, so I'm going to come in interview during the day?” “No. That biases people who can't take time off.” And, on some level, it almost seems to distill down to no one likes any way that there is of interviewing candidates, and figuring out a way that accommodates everyone is a sort of a fool's errand. It seems like there is no way that won't get you yelled at.Emma: I think there needs to be almost like a choose your own adventure. What is going to set you up for success and also allow you to see if you want to even work that kind of a job in the first place? Because I thought on paper, open-source maintainer sounds awesome. And upon looking into the challenges, I'm like, “You know what? I think I'd hate this job.”And I pulled out and I didn't waste their time and they didn't waste mine. So, when you get down to it, honestly, I wish I didn't have to write this book. Did it bring me a lot of benefit? Yeah. Let's not sugarcoat that. It allowed me to pay off my medical debt and move across a continent, but that being said, I wish that we were at a point in time where that did not need to exist.Corey: One of the things that absolutely just still gnaws at me even years later, is I interviewed at Google twice, and I didn't get an offer either time, I didn't really pass their technical screen either time. The second one that really sticks out in my mind where it was, “Hey, write some code in a Google Doc while we watch remotely,” and don't give you any context or hints on this. And just it was—the entire process was sitting there listening to them basically, like, “Nope, not what I'm thinking about. Nope, nope, nope.” It was… by the end of that conversation, I realized that if they were going to move forward—which they didn't—I wasn't going to because I didn't want to work with people that were that condescending and rude.And I've held by it; I swore I would never apply there again and I haven't. And it's one of those areas where, did I have the ability to do the job? I can say in hindsight, mostly. Were there things I was going to learn as I went? Absolutely, but that's every job.And I'm realizing as I see more and more across the ecosystem, that they were an outlier in a potentially good way because in so many other places, there's no equivalent of the book that you have written that is given to the other side of the table: how to effectively interview candidates. People lose sight of the fact that it's a sales conversation; it's a two-way sale, they have to convince you to hire them, but you also have to convince them to work with you. And even in the event that you pass on them, you still want them to say nice things about you because it's a small industry, all things considered. And instead, it's just been awful.Emma: I had a really shitty interview, and let me tell you, they have asked me subsequently if I would re-interview with them. Which sucks; it's a product that I know and love, and I've talked about this, but I had the worst experience. Let me clarify, I had a great first interview with them, and I was like, “I'm just not ready to move to Australia.” Which is where the job was. And then they contacted me again a year later, and it was the worst experience of my life—same recruiter—it was the ego came out.And I will tell you what, if you treat your candidates like shit, they will remember and they will never recommend people interview for you. [laugh]. I also wanted to mention about accessibility because—so we talked about, oh, give candidates the choice, which I think the whole point of an interview should be setting your candidates up for success to show you what they can do. And I talked with [Stephen 00:14:09]—oh, my gosh, I can't remember his last name—but he is a quadriplegic and he types with a mouthstick. And he was saying he would go to technical interviews and they would not be prepared to set him up for success.And they would want to do these pair programming, or, like, writing on a whiteboard. And it's not that he can't pair program, it's that he was not set up for success. He needed a mouthstick to type and they were not prepared to help them with that. So, it's not just about the commitment that people need. It's also about making sure that you are giving candidates what they need to give the best interview possible in an artificial environment.Corey: One approach that people have taken is, “Ah, I'm going to shortcut this and instead of asking people to write code, I'm going to look at their work on GitHub.” Which is, in some cases, a great way to analyze what folks are capable of doing. On the other, well, there's a lot of things that play into that. What if they're working in environment where they don't have the opportunity to open-source their work? What if people consider this a job rather than an all-consuming passion?I know, perish the thought. We don't want to hire people like that. Grow up. It's not useful, and it's not helpful. It's not something that applies universally, and there's an awful lot of reasons why someone's code on GitHub might be materially better—or worse—than their work product. I think that's fine. It's just a different path toward it.Emma: I don't use GitHub for largely anything except just keeping repositories that I need. I don't actively update it. And I have, like, a few thousand followers; I'm like, “Why the hell do you guys follow me? I don't do anything.” It's honestly a terrible representation.That being said, you don't need to have a GitHub repository—an active one—to showcase your skills. There are many other ways that you can show a potential employer, “Hey, I have a lot of skills that aren't necessarily showcased on my resume, but I like to write blogs, I like to give tech talks, I like to make YouTube videos,” things of that nature.Corey: I had a manager once who refused to interview anyone who didn't have a built-out LinkedIn profile, which is also one of these bizarre things. It's, yeah, a lot of people don't feel the need to have a LinkedIn profile, and that's fine. But the idea that, “Oh, yeah, they have this profile they haven't updated in a couple years, it's clearly they're not interested in looking for work.” It's, yeah. Maybe—just a thought here—your ability to construct a resume and build it out in the way that you were expecting is completely orthogonal to how effective they might be in the role. The idea that someone not having a LinkedIn profile somehow implies that they're sketchy is the wrong lesson to take from all of this. That site is terrible.Emma: Especially when you consider the fact that LinkedIn is primarily used in the United States as a social—not social networking—professional networking tool. In Germany, they use Xing as a platform; it's very similar to LinkedIn, but my point is, if you're solely looking at someone's LinkedIn as a representation of their ability to do a job, you're missing out on many candidates from all over the world. And also those who, yeah, frankly, just don't—like, they have more important things to be doing than updating their LinkedIn profile. [laugh].Corey: On some level, it's the idea of looking at a consultant, especially independent consultant type, when their website is glorious and up-to-date and everything's perfect, it's, oh, you don't really have any customers, do you? As opposed to the consultants you know who are effectively sitting there with a waiting list, their website looks like crap. It's like, “Is this Geocities?” No. It's just that they're too busy working on the things that bring the money instead of the things that bring in business, in some respects.Let's face it, websites don't. For an awful lot of consulting work, it's word of mouth. I very rarely get people finding me off of Google, clicking a link, and, “Hey, my AWS bill is terrible. Can you help us with it?” It happens, but it's not something that happens so frequently that we want to optimize for it because that's not where the best customers have been coming from. Historically, it's referrals, it's word of mouth, it's people seeing the aggressive shitposting I engage in on Twitter and saying, “Oh, that's someone that should help me with my Amazon bill.” Which I don't pretend to understand, but I'm still going to roll with it.Emma: You had mentioned something about passion earlier, and I just want to say, if you're a hiring manager or recruiter, you shouldn't solely be looking at candidates who superficially look like they're passionate about what they do. Yes, that is—it's important, but it's not something that—like, I don't necessarily choose one candidate over the other because they push commits, and open pull requests on GitHub, and open-source, and stuff. You can be passionate about your job, but at the end of the day, it's still a job. For me, would I be working if I had to? No. I'd be opening a bookstore because that's what I would really love to be doing. But that doesn't mean I'm not passionate about my job. I just show it in different ways. So, just wanted to put that out there.Corey: Oh, yeah. The idea that you must eat, sleep, live, and breathe is—hell with that. One of the reasons that we get people to work here at The Duckbill Group is, yeah, we care about getting the job done. We don't care about how long it takes or when you work; it's oh, you're not feeling well? Take the day off.We have very few things that are ‘must be done today' style of things. Most of those tend to fall on me because it's giving a talk at a conference; they will not reschedule the conference for you. I've checked. So yeah, that's important, but that's not most days.Emma: Yeah. It's like programming is my job, it's not my identity. And it's okay if it is your primary hobby if that is how you identify, but for me, I'm a person with actual hobbies, and, you know, a personality, and programming is just a job for me. I like my job, but it's just a job.Corey: And on the side, you do interesting things like wrote a book. You mentioned earlier that it wound up paying off some debt and helping cover your move across an ocean. Let's talk a little bit about that because I'm amenable to the idea of side projects that accidentally have a way of making money. That's what this podcast started out as. If I'm being perfectly honest, and started out as something even more self-serving than that.It's, well if I reach out to people in this industry that are doing interesting things and ask them to grab a cup of coffee, they'll basically block me, whereas if I ask them to, would you like to appear on my podcast, they'll clear time on their schedule. I almost didn't care if my microphone was on or not when I was doing these just because it was a chance to talk to really interesting people and borrow their brain, people reached out asking they can sponsor it, along with the newsletter and the rest, and it's you want to give me money? Of course, you can give me money. How much money? And that sort of turned into a snowball effect over time.Five years in, it's turned into something that I would never have predicted or expected. But it's weird to me still, how effective doing something you're actually passionate about as a side project can sort of grow wings on its own. Where do you stand on that?Emma: Yeah, it's funny because with the exception of the online courses that I've worked with—I mentioned LinkedIn Learning and Frontend Masters, which I knew were paid opportunities—none of my side projects started out for financial reasonings. The podcast that we started was purely for fun, and the sponsors came to us. Now, I will say right up front, we all had pretty big social media followings, and my first piece of advice to anyone looking to get into side projects is, don't focus so much on making money at the get-go. Yes, to your point, Corey, focus on the stuff you're passionate about. Focus on engaging with people on social media, build up your social media, and at that point, okay, monetization will slowly find its way to you.But yeah, I say if you can monetize the heck out of your work, go for it. But also, free content is also great. I like to balance my paid content with my free content because I recognize that not everyone can afford to pay for some of this information. So, I generally always have free alternatives. And for this book that we published, one of the things that was really important to me was keeping it affordable.The first publish I did was $10 for the book. It was like a 250-page book. It was, like, $10 because again, I was not in it for the money. And when I redid the book with the egghead.io team, the same team that did Epic React with Kent C. Dodds, I said, “I want to keep this affordable.” So, we made sure it was still affordable, but also that we had—what's it called? Parity pricing? Pricing parity, where depending on your geographic location, the price is going to accommodate for how the currency is doing. So, yes, I would agree. Side project income for me allows me to do incredible stuff, but it wasn't why I got into it in the first place. It was genuinely just a nice-to-have.Corey: I haven't really done anything that asks people for money directly. I mean, yeah, I sell t-shirts on the website, and mugs, and drink umbrellas—don't get me started—but other than that and the charity t-shirt drive I do every year, I tend to not be good at selling things that don't have a comma in the price tag. For me, it was about absolutely building an audience. I tend to view my Twitter follower count as something of a proxy for it, but the number I actually care about, the audience that I'm focused on cultivating, is newsletter subscribers because no social media platform that we've ever seen has lasted forever. And I have to imagine that Twitter will one day wane as well.But email has been here since longer than we'd been alive, and by having a list of email addresses and ways I can reach out to people on an ongoing basis, I can monetize that audience in a more direct way, at some point should I need them to. And my approach has been, well, one, it's a valuable audience for some sponsors, so I've always taken the asking corporate people for money is easier than asking people for personal money, plus it's a valuable audience to them, so it tends to blow out a number of the metrics that you would normally expect of, oh, for this audience size, you should generally be charging Y dollars. Great. That makes sense if you're slinging mattresses or free web hosting, but when it's instead, huh, these people buy SaaS enterprise software and implement it at their companies, all of economics tend to start blowing apart. Same story with you in many respects.The audience that you're building is functionally developers. That is a lucrative market for the types of sponsors that are wise enough to understand that—in a lot of cases these days—which product a company is going to deploy is not dictated by their exec so much as it is the bottom-up adoption path of engineers who like the product.Emma: Mm-hm. Yeah, and I think once I got to maybe around 10,000 Twitter followers is when I changed my mentality and I stopped caring so much about follower count, and instead I just started caring about the people that I was following. And the number is a nice-to-have but to be honest, I don't think so much about it. And I do understand, yes, at that point, it is definitely a privilege that I have this quote-unquote, “Platform,” but I never see it as an audience, and I never think about that “Audience,” quote-unquote, as a marketing platform. But it's funny because there's no right or wrong. People will always come to you and be like, “You shouldn't monetize your stuff.” And it's like—Corey: “Cool. Who's going to pay me then? Not you, apparently.”Emma: Yeah. It's also funny because when I originally sold the book, it was $10 and I got so many people being like, “This is way too cheap. You should be charging more.” And I'm like, “But I don't care about the money.” I care about all the people who are unemployed and not able to survive, and they have families, and they need to get a job and they don't know how.That's what I care about. And I ended up giving away a lot of free books. My mantra was like, hey if you've been laid off, DM me. No questions asked, I'll give it to you for free. And it was nice because a lot of people came back, even though I never asked for it, they came back and they wanted to purchase it after the fact, after they'd gotten a job.And to me that was like… that was the most rewarding piece. Not getting their money; I don't care about that, but it was like, “Oh, okay. I was actually able to help you.” That is what's really the most rewarding. But yeah, certainly—and back really quickly to your email point, I highly agree, and one of the first things that I would recommend to anyone looking to start a side product, create free content so that you have a backlog that people can look at to… kind of build trust.Corey: Give it away for free, but also get emails from people, like a trade for that. So, it's like, “Hey, here's a free guide on how to start a podcast from scratch. It's free, but all I would like is your email.” And then when it comes time to publish a course on picking the best audio and visual equipment for that podcast, you have people who've already been interested in this topic that you can now market to.This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: I'm not sitting here trying to judge anyone for the choices that they make at all. There are a lot of different paths to it. I'm right there with you. One of the challenges I had when I was thinking about, do I charge companies or do I charge people was that if I'm viewing it through a lens of audience growth, well, what stuff do I gate behind a paywall? What stuff don't I? Well, what if I just—Emma: Mm-hm.Corey: —gave it all away? And that way I don't have to worry about the entire class of problems that you just alluded to of, well, how do I make sure this is fair? Because a cup of coffee in San Francisco is, what, $14 in some cases? Whereas that is significant in places that aren't built on an economy of foolishness. How do you solve for that problem? How do you deal with the customer service slash piracy issues slash all the other nonsense? And it's just easier.Emma: Yeah.Corey: Something I've found, too, is that when you're charging enough money to companies, you don't have to deal with an entire class of customer service problem. You just alluded to the other day that well, you had someone who bought your book and was displeased that it wasn't a how to write code from scratch tutorial, despite the fact that he were very clear on what it is and what it isn't. I don't pretend to understand that level of entitlement. If I spend 10 or 20 bucks on an ebook, and it's not very good, let's see, do I wind up demanding a refund from the author and making them feel bad about it, or do I say, “The hell with it.” And in my case, I—there is privilege baked into this; I get that, but it's I don't want to make people feel bad about what they've built. If I think there's enough value to spend money on it I view that as a one-way transaction, rather than chasing someone down for three months, trying to get a $20 refund.Emma: Yeah, and I think honestly, I don't care so much about giving refunds at all. We have a 30-day money-back guarantee and we don't ask any questions. I just asked this person for feedback, like, “Oh, what was not up to par?” And it was just, kind of like, BS response of like, “Oh, I didn't read the website and I guess it's not what I wanted.” But the end of the day, they still keep the product.The thing is, you can't police all of the people who are going to try to get your content for free if you're charging for it; it's part of it. And I knew that when I got into it, and honestly, my thing is, if you are circulating a book that helps you get a job in tech and you're sending it to all your friends, I'm not going to ask any questions because it's very much the sa—and this is just my morals here, but if I saw someone stealing food from a grocery store, I wouldn't tell on them because at the end of the day, if you're s—Corey: Same story. You ever see someone's stealing baby formula from a store? No, you didn't.Emma: Right.Corey: Keep walking. Mind your business.Emma: Exactly. Exactly. So, at the end of the day, I didn't necessarily care that—people are like, “Oh, people are going to share your book around. It's a PDF.” I'm like, “I don't care. Let them. It is what it is. And the people who wants to support and can, will.” But I'm not asking.I still have free blogs on data structures, and algorithms, and the interview stuff. I do still have content for free, but if you want more, if you want my illustrated diagrams that took me forever with my Apple Pencil, fair enough. That would be great if you could support me. If not, I'm still happy to give you the stuff for free. It is what it is.Corey: One thing that I think is underappreciated is that my resume doesn't look great. On paper, I have an eighth-grade education, and I don't have any big tech names on my resume. I have a bunch of relatively short stints; until I started this place, I've never lasted more than two years anywhere. If I apply through the front door the way most people do for a job, I will get laughed out of the room by the applicant tracking system, automatically. It'll never see a human.And by doing all these side projects, it's weird, but let's say that I shut down the company for some reason, and decide, ah, I'm going to go get a job now, my interview process—more or less, and it sounds incredibly arrogant, but roll with it for a minute—is, “Don't you know who I am? Haven't you heard of me before?” It's, “Here's my website. Here's all the stuff I've been doing. Ask anyone in your engineering group who I am and you'll see what pops up.”You're in that same boat at this point where your resume is the side projects that you've done and the audience you've built by doing it. That's something that I think is underappreciated. Even if neither one of us made a dime through direct monetization of things that we did, the reputational boost to who we are and what we do professionally seems to be one of those things that pays dividends far beyond any relatively small monetary gain from it.Emma: Absolutely, yeah. I actually landed my job interview with Spotify through Twitter. I was contacted by a design systems manager. And I was in the interview process for them, and I ended up saying, “You know, I'm not ready to move to Stockholm. I just moved to Germany.”And a year later, I circled back and I said, “Hey, are there any openings?” And I ended up re-interviewing, and guess what? Now, I have a beautiful home with my soulmate and we're having a child. And it's funny how things work out this way because I had a Twitter account. And so don't undervalue [laugh] social media as a tool in lieu of a resume because I don't think anyone at Spotify even saw my resume until it actually accepted the job offer, and it was just a formality.So yeah, absolutely. You can get a job through social media. It's one of the easiest ways. And that's why if I ever see anyone looking for a job on Twitter, I will retweet, and vouch for them if I know their work because I think that's one of the quickest ways to finding an awesome candidate.Corey: Back in, I don't know, 2010, 2011-ish. I was deep in the IRC weed. I was network staff on the old freenode network—not the new terrible one. The old, good one—and I was helping people out with various things. I was hanging out in the Postfix channel and email server software thing that most people have the good sense not to need to know anything about.And someone showed up and was asking questions about their config, and I was working with them, and teasing them, and help them out with it. And at the end of it, his comment was, “Wow, you're really good at this. Any chance you'd be interested in looking for jobs?” And the answer was, “Well, sure, but it's a global network. Where are you?”Well, he was based in Germany, but he was working remotely for Spotify in Stockholm. A series of conversations later, I flew out to Stockholm and interviewed for a role that they decided I was not a fit for—and again, they're probably right—and I often wonder how my life would have gone differently if the decision had gone the other way. I mean, no hard feelings, please don't get me wrong, but absolutely, helping people out, interacting with people over social networks, or their old school geeky analogs are absolutely the sorts of things that change lives. I would never have thought to apply to a role like that if I had been sitting here looking at job ads because who in the world would pick up someone with relatively paltry experience and move them halfway around the world? This was like a fantasy, not a reality.Emma: [laugh].Corey: It's the people you get to know—Emma: Yeah.Corey: —through these social interactions on various networks that are worth… they're worth gold. There's no way to describe it other than that.Emma: Yeah, absolutely. And if you're listening to this, and you're discouraged because you got turned down for a job, we've all been there, first of all, but I remember being disappointed because I didn't pass my first round of interviews of Google the first time I interviewed with them, and being, like, “Oh, crap, now I can't move to Munich. What am I going to do with my life?” Well, guess what, look where I am today. If I had gotten that job that I thought was it for me, I wouldn't be in the happiest phase of my life.And so if you're going through it—obviously, in normal circumstances where you're not frantically searching for a job; if you're in more of a casual life job search—and you've been let go from the process, just realize that there's probably something bigger and better out there for you, and just focus on your networking online. Yeah, it's an invaluable tool.Corey: One time when giving a conference talk, I asked, “All right, raise your hand if you have never gone through a job interview process and then not been offered the job.” And a few people did. “Great. If your hand is up, aim higher. Try harder. Take more risks.”Because fundamentally, job interviews are two-way streets and if you are only going for the sure thing jobs, great, stretch yourself, see what else is out there. There's no perfect attendance prize. Even back in school there wasn't. It's the idea of, “Well, I've only ever taken the easy path because I don't want to break my streak.” Get over it. Go out and interview more. It's a skill, unlike most others that you don't get to get better at unless you practice it.So, you've been in a job for ten years, and then it's time to move on—I've talked to candidates like this—their interview skills are extremely rusty. It takes a little bit of time to get back in the groove. I like to interview every three to six months back when I was on the job market. Now that I, you know, own the company and have employees, it looks super weird if I do it, but I miss it. I miss those conversations. I miss the aspects—Emma: Yes.Corey: —of exploring what the industry cares about.Emma: Absolutely. And don't underplay the importance of studying the foundational language concepts. I see this a lot in candidates where they're so focused on the newest and latest technologies and frameworks, that they forgot foundational JavaScript, HTML, and CSS. Many companies are focused primarily on these plain language concepts, so just make sure that when you are ready to get back into interviewing and enhance that skill, that you don't neglect the foundation languages that the web is built on if you're a web developer.Corey: I'd also take one last look around and realize that every person you admire, every person who has an audience, who is a known entity in the space only has that position because someone, somewhere did them a favor. Probably lots of someones with lots of favors. And you can't ever pay those favors back. All you can do is pay it forward. I repeatedly encourage people to reach out to me if there's something I can do to help. And the only thing that surprises me is how few people in the audience take me up on that. I'm talking to you, listener. Please, if I can help you with something, please reach out. I get a kick out of doing that sort of thing.Emma: Absolutely. I agree.Corey: Emma, thank you so much for taking the time to speak with me today. If people want to learn more, where can they find you?Emma: Well, you can find me on Twitter. It's just @EmmaBostian, I'm, you know, shitposting over there on the regular. But sometimes I do tweet out helpful things, so yeah, feel free to engage with me over there. [laugh].Corey: And we will, of course, put a link to that in the [show notes 00:35:42]. Thank you so much for taking the time to speak with me today. I appreciate it.Emma: Yeah. Thanks for having me.Corey: Emma Bostian, software engineer at Spotify and oh, so very much more. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an incoherent ranting comment mentioning that this podcast as well failed to completely teach you JavaScript.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

After a chilling encounter with the Pale Rider, our heroes meet a new ally who shares their animosity towards the Barbarossa Gang. Git ready, y'all! Lu'luh Jacksplit's here, and she's ready to ride! Next stop: Sunset City!  If you enjoy this podcast please help us out by leaving a review and sharing it with your fellow adventurers. Want more 3BH in your life? You can now buy merchandise here!  Support us on Patreon at patreon.com/tbhalflings for your Shirefolk Shoutout and Bonus Episodes including Campfire Chats where we dive into each episode of Outlaws & Obelisks  Connect with us on Twitter, Instagram, and Facebook @tbhalflings, on our Discord, or email secondbreakfast@tbhalflings.com See omnystudio.com/listener for privacy information.

Watch the live stream: Watch on YouTube About the show Special guest: Yael Mintz Sponsored by us: Check out the courses over at Talk Python And Brian's book too! Michael #1: awesome-htmx An awesome list of resources about htmx such as articles, posts, videos, talks and more. Good for all sorts of examples and multiple languages We get a few nice shoutouts, thanks Brian #2: Python 3.10 is here !!!! As of Monday. Of course I have it installed on Mac and Windows. Running like a charm. You can watch the Release Party recording. It's like 3 hours. And starts with hats. Pablo's is my fav. Also a What's New video which aired before that with Brandt Bucher, Lukasz Llanga ,and Sebastian Ramirez (33 min) Includes a deep dive into structural pattern matching that I highly recommend. Reminder of new features: PEP 623 -- Deprecate and prepare for the removal of the wstr member in PyUnicodeObject. PEP 604 -- Allow writing union types as X | Y PEP 612 -- Parameter Specification Variables PEP 626 -- Precise line numbers for debugging and other tools. PEP 618 -- Add Optional Length-Checking To zip. bpo-12782: Parenthesized context managers are now officially allowed. PEP 632 -- Deprecate distutils module. PEP 613 -- Explicit Type Aliases PEP 634 -- Structural Pattern Matching: Specification PEP 635 -- Structural Pattern Matching: Motivation and Rationale PEP 636 -- Structural Pattern Matching: Tutorial PEP 644 -- Require OpenSSL 1.1.1 or newer PEP 624 -- Remove Py_UNICODE encoder APIs PEP 597 -- Add optional EncodingWarning Takeaway I wasn't expecting: black doesn't handle Structural Pattern Matching yet. Yael #3: Prospector (almost) All Python analysis tools together Instead of running pylint, pycodestyle, mccabe and other separately, prospector allows you to bundle them all together Includes the common Pylint and Pydocstyle / Pep257, but also some other less common goodies, such as Mccabe, Dodgy, Vulture, Bandit, Pyroma and many others Relatively easy configuration that supports profiles, for different cases Built-in support for celery, Flask and Django frameworks https://soshace.com/how-to-use-prospector-for-python-static-code-analysis/ Michael #4: Rich Pandas DataFrames via Avi Perl, by Khuyen Tran Create animated and pretty Pandas Dataframe or Pandas Series (in the terminal, using Rich) I just had Will over on Talk Python last week BTW: Terminal magic with Rich and Textual Can limit rows, control the animation speed, show head or tail, go “full screen” with clear, etc. Example: from sklearn.datasets import fetch_openml from rich_dataframe import prettify speed_dating = fetch_openml(name='SpeedDating', version=1)['frame'] table = prettify(speed_dating) Brian #5: Union types, baby! From Python 3.10: “PEP 604 -- Allow writing union types as X | Y” Use as possibly not intended, to avoid Optional: def foo(x: str | None = None) -> None: pass 3.9 example: from typing import Optional def foo(x: Optional[str] = None) -> None: pass But here's the issue. I need to support Python 3.9 at least, and probably early, what should I do? For 3.7 and above, you can use from __future__ import annotations. And of course Anthony Sottile worked this into pyupgrade and Adam Johnson wrote about it: Python Type Hints - How to Upgrade Syntax with pyupgrade This article covers: PEP 585 added generic syntax to builtin types. This allows us to write e.g. list[int] instead of using typing.List[int]. PEP 604 added the | operator as union syntax. This allows us to write e.g. int | str instead of typing.Union[int, str], and int | None instead of typing.Optional[int]. How to use these. What they look like. And how to use pyupgrade to just convert your code for you if you've already written it the old way. Awesome. Yael #6: Make your code darker - Improving Python code incrementally The idea behind Darker is to reformat code using Black (and optionally isort), but only apply new formatting to regions which have been modified by the developer Instead of having one huge PR, darker allows you to reformat the code gradually, when you're touching the code for other reasons.. Every modified line, will be black formatted Once added to Git pre-commit-hook, or added to PyCharm **/ VScode the formatting will happen automatically Extras Brian: I got a couple PRs accepted into pytest. So that's fun: 9133: Add a deselected parameter to assert_outcomes() 9134: Add a pythonpath setting to allow paths to be added to sys.path I've tested, provided feedback, written about, and submitted issues to the project before. I've even contributed some test code. But these are the first source code contributions. It was a cool experience. Great team there at pytest. Michael: New htmx course: HTMX + Flask: Modern Python Web Apps, Hold the JavaScript auto-optional: Due to the comments on the show I remembered to add support for Union[X, None] and python 10's X | None syntax. Coverage 6.0 released Django 3.2.8 released Yael: data-oriented-programming - an innovative approach to coding without OOP, with an emphasis on code and data separation, which simplifies state management and eases concurrency Help us to make Cornell awesome

Steve and AJ talk with Max Kordek, founder of his startup Lisk, which is geared towards helping JavaScript developers use the blockchain to develop new applications for new industries. We delve deep into the origins and base technologies of the blockchain, how it has been used, and how it can be used in the future. They also discuss Lisk, it's purpose, and how Max hopes their SDK will be used by developers to explore the blockchain and find brand new applications for it. Panel AJ O'NealSteve Edwards Guest Max Kordek Sponsors Dev Influencers AcceleratorRaygun | Click here to get started on your free 14-day trialPodcastBootcamp.io Links GitHub | LiskHackonLiskLiskMastering blockchain: Meet Lisk, a blockchain platform for JavaScript developersBlog Archives | LiskIntroducing the Lisk Grant ProgramThe 5th Anniversary of Lisk NetworkIntroducing Lisk Interoperability - YouTubeLisk International - YouTubeEvents - YouTubeLisk - DiscordLisk CommunityLisk - RedditLisk - YouTubeTwitter: Lisk ( @LiskHQ )Max Kordek - YouTubeTwitter: Max Kordek | HODLing the Lisk Gem ( @maxkordek ) Picks AJ- Blockchain Backer on TeachableAJ- Blockchain Backer - YouTubeAJ- HashcashAJ- Cryptocurrency is an abject disasterAJ- Nyan Cat NFTAJ- Walmart urges its suppliers to use IBM blockchain technologyAJ- Ep. 139 – Smart Contracts & Oracles – insights from ChainlinkMax- Technology | NASA Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards Special Guest: Max Kordek.

Steve and AJ talk with Max Kordek, founder of his startup Lisk, which is geared towards helping JavaScript developers use the blockchain to develop new applications for new industries. We delve deep into the origins and base technologies of the blockchain, how it has been used, and how it can be used in the future. They also discuss Lisk, it’s purpose, and how Max hopes their SDK will be used by developers to explore the blockchain and find brand new applications for it. Panel AJ O'Neal Steve Edwards Guest Max Kordek Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial PodcastBootcamp.io Links GitHub | Lisk HackonLisk Lisk Mastering blockchain: Meet Lisk, a blockchain platform for JavaScript developers Blog Archives | Lisk Introducing the Lisk Grant Program The 5th Anniversary of Lisk Network Introducing Lisk Interoperability - YouTube Lisk International - YouTube Events - YouTube Lisk - Discord Lisk Community Lisk - Reddit Lisk - YouTube Twitter: Lisk ( @LiskHQ ) Max Kordek - YouTube Twitter: Max Kordek | HODLing the Lisk Gem ( @maxkordek ) Picks AJ- Blockchain Backer on Teachable AJ- Blockchain Backer - YouTube AJ- Hashcash AJ- Cryptocurrency is an abject disaster AJ- Nyan Cat NFT AJ- Walmart urges its suppliers to use IBM blockchain technology AJ- Ep. 139 – Smart Contracts & Oracles – insights from Chainlink Max- Technology | NASA Contact AJ: AJ ONeal CoolAJ86 on GIT Beyond Code Bootcamp Beyond Code Bootcamp | GitHub Follow Beyond Code Bootcamp | Facebook Twitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Steve: Twitter: Steve Edwards ( @wonder95 ) GitHub: Steve Edwards ( wonder95 ) LinkedIn: Steve Edwards

Longtime listener and friend of the show, Gio Lodi, released a book y'all should check out and Chris and Steph ruminate on a listener question about tension around marketing in open-source. Say No To More Process, Say Yes To Trust by German Velasco (https://thoughtbot.com/blog/say-no-to-more-process-say-yes-to-trust) Test-Driven Development in Swift with SwiftUI and Combine by Gio Lodi (https://tddinswift.com/) Transcript: CHRIS: Our golden roads. STEPH: All right. I am also golden. CHRIS: [vocalization] STEPH: Oh, I haven't listened to that episode where I just broke out in song in the middle. Oh, you're about to add the [vocalization] [chuckles]. CHRIS: I don't know why, though. Oh, golden roads, Golden Arches. STEPH: Golden Arches, yeah. CHRIS: Man, I did not know that my brain was doing that, but my brain definitely connected those without telling me about it. STEPH: [laughs] CHRIS: It's weird. People talk often about the theory that phones are listening, and then you get targeted ads based on what you said. But I'm almost certain it's actually the algorithms have figured out how to do the same intuitive leaps that your brain does. And so you'll smell something and not make the nine steps in between, but your brain will start singing a song from your childhood. And you're like, what is going on? Oh, right, because when I was watching Jurassic Park that one time, we were eating this type of chicken, and therefore when I smell paprika, Jurassic Park theme song. I got it, of course. STEPH: [laughs] CHRIS: And I think that's actually what's happening with the phones. That's my guess is that you went to a site, and the phones are like, cool, I got it, adjacent to that is this other thing, totally. Because I don't think the phones are listening. Occasionally, I think the phones are listening, but mostly, I don't think the phones are listening. STEPH: I definitely think the phones are listening. CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey. So we have a bit of exciting news where we received an email from Gio Lodi, who is a listener of The Bike Shed. And Gio sent an email sharing with us some really exciting news that they have published a book on Test-Driven Development in Swift. And they acknowledge us in the acknowledgments of the book. Specifically, the acknowledgment says, "I also want to thank Chris Toomey and Steph Viccari, who keep sharing ideas on testing week after week on The Bike Shed Podcast." And that's just incredible. I'm so blown away, and I feel officially very famous. CHRIS: This is how you know you're famous when you're in the acknowledgments of a book. But yeah, Gio is a longtime listener and friend of the show. He's written in many times and given us great tips, and pointers, and questions, and things. And I've so appreciated Gio's voice in the community. And it's so wonderful, frankly, to hear that he has gotten value out of the show and us talking about testing. Because I always feel like I'm just regurgitating things that I've heard other people saying about testing and maybe one or two hard-learned truths that I've found. But it's really wonderful. And thank you so much, Gio. And best of luck for anyone out there who is doing Swift development and cares about testing or test-driven development, which I really think everybody should. Go check out that book. STEPH: I must admit my Swift skills are incredibly rusty, really non-existent at this point. It's been so long since I've been in that world. But I went ahead and purchased a copy just because I think it's really cool. And I suspect there are a lot of testing conversations that, regardless of the specific code examples, still translate. At least, that's the goal that you and I have when we're having these testing conversations. Even if they're not specific to a language, we can still talk about testing paradigms and strategies. So I purchased a copy. I'm really looking forward to reading it. And just to change things up a bit, we're going to start off with a listener question today. So this listener question comes from someone very close to the show. It comes from Thom Obarski. Hi, Thom. And Thom wrote in, "So I heard on a recent podcast I was editing some tension around marketing and open source. Specifically, a little perturbed at ReactJS that not only were people still dependent on a handful of big companies for their frameworks, but they also seem to be implying that the cachet of Facebook and having developer mindshare was not allowing smaller but potentially better solutions to shine through. In your opinion, how much does marketing play in the success of an open-source project framework rather than actually being the best tool for the job?" So a really thoughtful question. Thanks, Thom. Chris, I'm going to kick it over to you. What are your thoughts about this question? CHRIS: Yeah, this is a super interesting one. And thank you so much, Thom, although I'm not sure that you're listening at this point. But we'll send you a note that we are replying to your question. And when I saw this one come through, it was interesting. I really love the kernel of the discussion here, but it is, again, very difficult to tease apart the bits. I think that the way the question was framed is like, oh, there's this bad thing that it's this big company that has this big name, and they're getting by on that. But really, there are these other great frameworks that exist, and they should get more of the mindshare. And honestly, I'm not sure. I think marketing is a critically important aspect of the work that we do both in open source and, frankly, everywhere. And I'm going to clarify what I mean by that because I think it can take different shapes. But in terms of open-source, Facebook has poured a ton of energy and effort and, frankly, work into React as a framework. And they're also battle testing it on facebook.com, a giant website that gets tons of traffic, that sees various use cases, that has all permissions in there. They're really putting it through the wringer in that way. And so there is a ton of value just in terms of this large organization working on and using this framework in the same way that GitHub and using Rails is a thing that is deeply valuable to us as a community. So I think having a large organization associated with something can actually be deeply valuable in terms of what it produces as an outcome for us as consumers of that open-source framework. I think the other idea of sort of the meritocracy of the better framework should win out is, I don't know, it's like a Field of Dreams. Like, if you build it, they will come. It turns out I don't believe that that's actually true. And I think selling is a critical part of everything. And so if I think back to DHH's original video from so many years ago of like, I'm going to make a blog in 15 minutes; look at how much I'm not doing. That was a fantastic sales pitch for this new framework. And he was able to gain a ton of attention by virtue of making this really great sales pitch that sold on the merits of it. But that was marketing. He did the work of marketing there. And I actually think about it in terms of a pull request. So I'm in a small organization. We're in a private repo. There's still marketing. There's still sales to be done there. I have to communicate to someone else the changes that I'm making, why it's valuable to the system, why they should support this change, this code coming into the codebase. And so I think that sort of communication is as critical to the whole conversation. And so the same thing happens at the level of open source. I would love for the best framework to always win, but we also need large communities with Stack Overflow answers and community-supported plugins and things like that. And so it's a really difficult thing to treat marketing as just other, this different, separate thing when, in fact, I think they're all intertwined. And marketing is critically important, and having a giant organization behind something can actually have negative aspects. But I think overall; it really is useful in a lot of cases. Those are some initial thoughts. What do you think, Steph? STEPH: Yeah, those are some great initial thoughts. I really agree with what you said. And I also like how you brought in the comparison of pull requests and how sales is still part of our job as developers, maybe not in the more traditional sense but in the way that we are marketing and communicating with the team. And circling back to what you were saying earlier about a bit how this is phrased, I think I typically agree that there's nothing nefarious that's afoot in regards to just because a larger company is sponsoring an open-source project or they are the ones responsible for it, I don't think there's anything necessarily bad about that. And I agree with the other points that you made where it is helpful that these teams have essentially cultivated a framework or a project that is working for their team, that is helping their company, and then they have decided to open source it. And then, they have the time and energy that they can continue to invest in that project. And it is battle-tested because they are using it for their own projects as well. So it seems pretty natural that a lot of us then would gravitate towards these larger, more heavily supported projects and frameworks. Because then that's going to make our job easier and also give us more trust that we can turn to them when we do need help or have issues. Or, like you mentioned, when we need to look up documentation, we know that that's going to be there versus some of the other smaller projects. They may also be wonderful projects. But if they are someone that's doing this in their spare time just on the weekends and yet I'm looking for something that I need to be incredibly reliable, then it probably makes sense for me to go with something that is supported by a team that's getting essentially paid to work on that project, at least that they're backed by a larger company. Versus if I'm going with a smaller project where someone is doing some wonderful work, but realistically, they're also doing it more on the weekends or in their spare time. So boiling it down, it's similar to what you just said where marketing plays a very big part in open source, and the projects and frameworks that we adopt, and the things that we use. And I don't think that's necessarily a bad thing. CHRIS: Yeah. I think, if anything, it's possibly a double-edged sword. Part of the question was around does React get to benefit just by the cachet of Facebook? But Facebook, as a larger organization sometimes that's a positive thing. Sometimes there's ire that is directed at Facebook as an organization. And as a similar example, my experience with Google and Microsoft as large organizations, particularly backing open-source efforts, has almost sort of swapped over time, where originally, Microsoft there was almost nothing of Microsoft's open-source efforts that I was using. And I saw them as this very different shape of a company that I probably wouldn't be that interested in. And then they have deeply invested in things like GitHub, and VS Code, and TypeScript, and tons of projects that suddenly I'm like, oh, actually, a lot of what I use in the world is coming from Microsoft. That's really interesting. And at the same time, Google has kind of gone in the opposite direction for me. And I've seen some of their movements switch from like, oh Google the underdog to now they're such a large company. And so the idea that the cachet, as the question phrase, of a company is just this uniformly positive thing and that it's perhaps an unfair benefit I don't see that as actually true. But actually, as a more pointed example of this, I recently chose Svelte over React, and that was a conscious choice. And I went back and forth on it a few times, if we're being honest, because Svelte is a much smaller community. It does not have the large organizational backing that React or other frameworks do. And there was a certain marketing effort that was necessary to raise it into my visibility and then for me to be convinced that there is enough there, that there is a team that will maintain it, and that there are reasons to choose that and continue with it. And I've been very happy with it as a choice. But I was very conscious in that choice that I'm choosing something that doesn't have that large organizational backing. Because there's a nicety there of like, I trust that Facebook will probably keep investing in React because it is the fundamental technology of the front end of their platform. So yeah, it's not going to go anywhere. But I made the choice of going with Svelte. So it's an example of where the large organization didn't win out in my particular case. So I think marketing is a part of the work, a part of the conversation. It's part of communication. And so I am less negative on it, I think, than the question perhaps was framed, but as always, it depends. STEPH: Yeah, I'm trying to think of a scenario where I would be concerned about the fact that I'm using open source that's backed by a specific large company or corporation. And the main scenario I can think of is what happens when you conflict or if you have values that conflict with a company that is sponsoring that project? So if you are using an open-source project, but then the main community or the company that then works on that project does something that you really disagree with, then what do you do? How do you feel about that situation? Do you continue to use that open-source project? Do you try to use a different open-source project? And I had that conversation frankly with myself recently, thinking through what to do in that situation and how to view it. And I realize this may not be how everybody views it, and it's not appropriate for all situations. But I do typically look at open-source projects as more than who they are backed by, but the community that's actively working on that project and who it benefits. So even if there is one particular group that is doing something that I don't agree with, that doesn't necessarily mean that wholesale I no longer want to be a part of this community. It just means that I still want to be a part, but I still want to share my concerns that I think a part of our community is going in a direction that I don't agree with or I don't think is a good direction. That's, I guess, how I reason with myself; even if an open-source project is backed by someone that I don't agree with, either one, you can walk away. That seems very complicated, depending on your dependencies. Or two, you find ways to then push back on those values if you feel that the community is headed in a direction that you don't agree with. And that all depends on how comfortable you are and how much power you feel like you have in that situation to express your opinion. So it's a complicated space. CHRIS: Yeah, that is a super subtle edge case of all of this. And I think I aligned with what you said of trying to view an open-source project as more generally the community that's behind it as opposed to even if there's a strong, singular organization behind it. But that said, that's definitely a part of it. And again, it's a double-edged sword. It's not just, oh, giant company; this is great. That giant company now has to consider this. And I think in the case of Facebook and React, that is a wonderful hiring channel for them. Now all the people that use React anywhere are like, "Oh man, I could go work at Facebook on React? That's exciting." That's a thing that's a marketing tool from a hiring perspective for them. But it cuts both ways because suddenly, if the mindshare moves in a different direction, or if Facebook as an organization does something complicated, then React as a community can start to shift away. Maybe you don't move the current project off of it, but perhaps you don't start the next one with it. And so, there are trade-offs and considerations in all directions. And again, it depends. STEPH: Yeah. I think overall, the thing that doesn't depend is marketing matters. It is a real part of the ecosystem, and it will influence our decisions. And so, just circling back to Thom's question, I think it does play a vital role in the choices that we make. CHRIS: Way to stick the landing. STEPH: Thanks. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Changing topics just a bit, what's new in your world? CHRIS: Well, we had what I would call a mini perfect storm this week. We broke the build but in a pretty solid way. And it was a little bit difficult to get it back under control. And it has pushed me ever so slightly forward in my desire to have a fully optimized CI and deploy pipeline. Mostly, I mean that in terms of ratcheting. I'm not actually going to do anything beyond a very small set of configurations. But to describe the context, we use pull requests because that's the way that we communicate. We do code reviews, all that fun stuff. And so there was a particular branch that had a good amount of changes, and then something got merged. And this other pull request was approved. And that person then clicked the rebase and merge button, which I have configured the repository, so that merge commits are not allowed because I'm not interested in that malarkey in our history. But merge commits or rebase and merge. I like that that makes sense. In this particular case, we ran into the very small, subtle edge case of if you click the rebase and merge button, GitHub is now producing a new commit that did not exist before, a new version of the code. So they're taking your changes, and they are rebasing them onto the current main branch. And then they're attempting to merge that in. And A, that was allowed. B, the CI configuration did not require that to be in a passing state. And so basically, in doing that rebase and merge, it produced an artifact in the build that made it fail. And then attempting to unwind that was very complicated. So basically, the rebase produced...there were duplicate changes within a given file. So Git didn't see it as a conflict because the change was made in two different parts of the file, but those were conflicting changes. So Git was like, this seems like it's fine. I can merge this, no problem. But it turns out from a functional perspective; it did not work. The build failed. And so now our main branch was failing and then trying to unwind that it just was surprisingly difficult to unwind that. And it really highlighted the importance of keeping the main branch green, keeping the build always passing. And so, I configured a few things in response to this. There is a branch protection rule that you can enable. And let me actually pull up the specific configuration that I set up. So I now have enabled require status checks to pass before merging, which, if we're being honest, I thought that was the default. It turns out it was not the default. So we are now requiring status checks to pass before merging. I'm fully aware of the awkward, painful like, oh no, the build is failing but also, we have a bug. We need to deploy this. We must get something merged in. So hopefully, if and when that situation presents itself, I will turn this off or somehow otherwise work around it. But for now, I would prefer to have this as a yeah; this is definitely a configuration we want. So require status checks to pass before merging and then require branches to be up to date before merging. So the button that does the rebase and merge, I don't want that to actually do a rebase on GitHub. I want the branch to already be up to date. Basically, I only ever want fast-forward merges on our main branch. So all code should be ahead of main, and we are simply updating what main points at. We are not creating new code. That code has run on CI, that version of the code specifically. We are fully rebased and up to date on top of main, and that's how we're going. STEPH: All of that is super interesting. I have a question about the workflow. I want to make sure I'm understanding it correctly. So let's say that I have issued a PR, and then someone else has merged into the main branch. So now my PR is behind me, and I don't have that latest commit. With the new configuration, can I still use the rebase and merge, or will I need to rebase locally and then push up my branch before I can merge into main but at least using the GitHub UI? CHRIS: I believe that you would be forced to rebase locally, force push, and then CI would rebuild, and that's what it is. So I think that's what require branches to be up to date before merging means. So that's my hope. That is the intention here. I do realize that's complicated. So this requirement, which I like, because again, I really want the idea that no, no, no, we, the developers, are in charge of that final state. That final state should always run as part of a build of CI on our pull request/branch before going into main. So no code should be new. There should be no new commits that have never been tested before going into main. That's my strong belief. I want that world. I realize that's...I don't know. Maybe I'm getting pedantic, or I'm a micromanager of the Git history or whatever. I'm fine with any of those insults that people want to lob at me. That's fine. But that's what I feel. That said, this is a nuisance. I'm fully aware of that. And so imagine the situation where we got a couple of different things that have been in flight. People have been working on different...say there are three pull requests that are all coming to completion at the same time. Then you start to go to merge something, and you realize, oh no, somebody else just merged. So you rebase, and then you wait for CI to build. And just as the CI is completing, somebody else merges something, and you're like, ah, come on. And so then you have to one more time rebase, push, wait for the build to be green. So I get that that is not an ideal situation. Right now, our team is three developers. So there are a few enough of us that I feel like this is okay. We can manage this via human intervention and just deal with the occasional weight. But in the back of my mind, of course, I want to find a better solution to this. So what I've been exploring…there's a handful of different utilities that I'm looking at, but they are basically merged queues as an idea. So there are three that I'm looking at, or maybe just two, but there's mergify.io, which is a hosted solution that does this sort of thing. And then Shopify has a merge queue implementation that they're running. So the idea with this is when you as a developer are ready to merge something, you add a label to it. And when you add that label, there's some GitHub Action or otherwise some workflow in the background that sees that this has happened and now adds it to a merge queue. So it knows all of the different things that might want to be merged. And this is especially important as the team grows so that you don't get that contention. You can just say, "Yes, I would like my changes to go out into production." And so, when you label it, it then goes into this merge queue. And the background system is now going to take care of any necessary rebases. It's going to sequence them, so it's not just constantly churning all of the branches. It's waiting because it knows the order that they're ideally going to go out in. If CI fails for any of them because rebasing suddenly, you're in an inconsistent state; if your build fails, then it will kick you out of the merge queue. It will let you know. So it will send you a notification in some manner and say, "Hey, hey, hey, you got to come look at this again. You've been kicked out of the merge queue. You're not going to production." But ideally, it adds that layer of automation to, frankly, this nuisance of having to keep things up to date and always wanting code to be run on CI and on a pull request before it gets into main. Then the ideal version is when it does actually merge your code, it pings you in Slack or something like that to say, "Hey, your changes just went out to production." Because the other thing I'm hoping for is a continuous deployment. STEPH: The idea of a merge queue sounds really interesting. I've never worked with a process like that. And one of the benefits I can see is if I know I'm ready for something to go like if I'm waiting on a green build and I'm like, hey, as soon as this is green, I'd really like for it to get merged. Then currently, I'm checking in on it, so I will restart the build. And then, every so often, I'm going back to say, "Okay, are you green? Are you green? Can I emerge?" But if I have a merge queue, I can say, "Hey, merge queue, when this is green, please go and merge it for me." If I'm understanding the behavior correctly, that sounds really nifty. CHRIS: I think that's a distinct but useful aspect of this is the idea that when you as a developer decide this PR is ready to go, you don't need to wait for either the current build or any subsequent builds. If there are rebases that need to happen, you basically say, "I think this code's good to go. We've gotten the necessary approvals. We've got the buy-in and the teams into this code." So cool, I now market as good. And you can walk away from it, and you will be notified either if it fails to get merged or if it successfully gets merged and deployed. So yes, that dream of like, you don't have to sit there watching the pot boil anymore. STEPH: Yeah, that sounds nice. I do have to ask you a question. And this is related to one of the blog posts that you and I love deeply and reference fairly frequently. And it's the one that's written by German Velasco about Say No to More Process, and Say Yes to Trust. And I'm wondering, based on the pain that you felt from this new commit, going into main and breaking the main build, how do you feel about that balance of we spent time investigating this issue, and it may or may not happen again, and we're also looking into these new processes to avoid this from happening? I'm curious what your thought process is there because it seems like it's a fair amount of work to invest in the new process, but maybe that's justified based on the pain that you felt from having to fix the build previously. CHRIS: Oh, I love the question. I love the subtle pushback here. I love this frame of mind. I really love that blog post. German writes incredible blog posts. And this is one that I just keep coming back to. In this particular case, when this situation occurred, we had a very brief...well, it wasn't even that brief because actually unwinding the situation was surprisingly painful, and we had some changes that we really wanted to get out, but now the build was broken. And so that churn and slowdown of our build pipeline and of our ability to actually get changes out to production was enough pain that we're like, okay, cool. And then the other thing is we actually all were in agreement that this is the way we want things to work anyway, that idea that things should be rebased and tested on CI as part of a pull request. And then we're essentially only doing fast-forward merges on the main branch, or we're fast forward merging main into this new change. That's the workflow that we wanted. So this configuration was really just adding a little bit of software control to the thing that we wanted. So it was an existing process in our minds. This is the thing we were trying to do. It's just kind of hard to keep up with, frankly. But it turns out GitHub can manage it for us and enforce the process that we wanted. So it wasn't a new process per se. It was new automation to help us hold ourselves to the process that we had chosen. And again, it's minimally painful for the team given the size that we're at now, but I am looking out to the future. And to be clear, this is one of the many things that fall on the list of; man, I would love to have some time to do this, but this is obviously not a priority right now. So I'm not allowed to do this. This is explicitly on the not allowed to touch list, but someday. I'm very excited about this because this does fundamentally introduce some additional work in the pipeline, and I don't want that. Like you said, is this process worth it for the very small set of times that it's going to have a bad outcome? But in my mind, the better version, that down the road version where we have a merge queue, is actually a better version overall, even with just a tiny team of three developers that are maybe never even conflicting in our merges, except for this one standout time that happens once every three months or whatever. This is still nicer. I want to just be able to label a pull request and walk away and have it do the thing that we have decided as a team that we want. So that's the dream. STEPH: Oh, I love that phrasing, to label a pull request and be able to walk away. Going back to our marketing, that really sells that merge queue to me. [laughs] Mid-roll Ad And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API. With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby. CHRIS: To be clear, and this is to borrow on some of Charity Majors' comments around continuous deployment and whatnot, is a developer should stay very close to the code if they are merging it. Because if we're doing continuous deployment, that's going to go out to production. If anything's going to happen, I want that individual to be aware. So ideally, there's another set of optimizations that I need to make on top of this. So we've got the merge queue, and that'll be great. Really excited about that. But if we're going to lean into this, I want to optimize our CI pipeline and our deployment pipeline as much as possible such that even in the worst case where there's three different builds that are fighting for contention and trying to get out, the longest any developer might go between labeling a pull request and saying, "This is good to go," and it getting out to production, again, even if they're contending with other PRs, is say 10, 15 minutes, something like that. I want Slack to notify them and them to then re-engage and keep an eye on things, see if any errors pop up, anything like that that they might need to respond to. Because they're the one that's got the context on the code at that point, and that context is decaying. The minute you've just merged a pull request and you're walking away from that code, the next day, you're like, what did I work on? I don't remember that at all. That code doesn't exist anymore in my brain. And so,,, staying close to that context is incredibly important. So there's a handful of optimizations that I've looked at in terms of the CircleCI build. I've talked about my not rebuilding when it actually gets fast-forward merged because we've already done that build on the pull request. I'm being somewhat pointed in saying this has to build on a pull request. So if it did just build on a pull request, let's not rebuild it on main because it's identically the same commit. CircleCI, I'm looking at you. Give me a config button for that, please. I would really love that config button. But there are a couple of other things that I've looked at. There's RSpec::Retry from NoRedInk, which will allow for some retry semantics. Because it will be really frustrating if your build breaks and you fall out of the merge queue. So let's try a little bit of retry logic on there, particularly around feature specs, because that's where this might happen. There's Knapsack Pro which is a really interesting thing that I've looked at, which does parallelization of your RSpec test suite. But it does it in a different way than say Circle does. It actually runs a build queue, and each test gets sent over, and they have build agents on their side. And it's an interesting approach. I'm intrigued. I think it could use some nice speed-ups. There's esbuild on the Heroku side so that our assets build so much more quickly. There are lots of things. I want to make it very fast. But again, this is on the not allowed to do it list. [laughs] STEPH: I love how most of the world has a to-do list, and you have this not-allowed to-do list that you're adding items to. And I'm really curious what all is on the not allowed to touch lists or not allowed to-do list. [laughs] CHRIS: I think this might be inherent to being a developer is like when I see a problem, I want to fix it. I want to optimize it. I want to tweak it. I want to make it so that that never happens again. But plenty of things...coming back to German's post of Say No to More Process, some things shouldn't be fixed, or the cost of fixing is so much higher than the cost of just letting it happen again and dealing with it manually at that moment. And so I think my inherent nature as a developer there's a voice in my head that is like, fix everything that's broken. And I'm like, sorry. Sorry, brain, I do not have that kind of time. And so I have to be really choosy about where the time goes. And this extends to the team as well. We need to be intentional around what we're building. Actually, there's a feeling that I've been feeling more acutely than ever, but it's the idea of this trade-off or optimization between speed and getting features out into the world and laying the right fundamentals. We're still very early on in this project, and I want to make sure we're thinking about things intentionally. I've been on so many projects where it's many years after it started and when I ask someone, "Hey, why do your background jobs work that way? That's a little weird." And they're like, "Yeah, that was just a thing that happened, and then it never changed. And then, we copied it and duplicated, and that pattern just got reinforced deeply within the app. And at this point, it would cost too much to change." I've seen that thing play out so many times at so many different organizations that I'm overwhelmed with that knowledge in the back of my head. And I'm like, okay, I got to get it just right. But I can't take the time that is necessary to get it, quote, unquote, "Just right." I do not have that kind of time. I got to ship some features. And this tension is sort of the name of the game. It's the thing I've been doing for my entire career. But now, given the role that I have with a very early-stage startup, I've never felt it more acutely. I've never had to be equally as concerned with both sides of that. Both matter all the more now than they ever have before, and so I'm kind of existing in that space. STEPH: I really like that phrasing of that space because that deeply resonates with me as well. And that not allowed to-do list I have a similar list. For me, it's just called a wishlist. And so it's a wishlist that I will revisit every so often, but honestly, most things on there don't get done. And then I'll clear it out every so often when I feel it's not likely that I'm going to get to it. And then I'll just start fresh. So I also have a similar this is what I would like to do if I had the time. And I agree that there's this inclination to automate as well. As soon as we have to do something that felt painful once, then we feel like, oh, we should automate it. And that's a conversation that I often have with myself is at what point is the cost of automation worthwhile versus should we just do this manually until we get to that point? So I love those nuanced conversations around when is the right time to invest further in this, and what is the impact? And what is the cost of it? And what are the trade-offs? And making that decision isn't always clear. And so I think that's why I really enjoy these conversations because it's not a clear rubric as to like, this is when you invest, and this is when you don't. But I do feel like being a consultant has helped me hone those skills because I am jumping around to different teams, and I'm recognizing they didn't do this thing. Maybe they didn't address this or invest in it, and it's working for them. There are some oddities. Like you said, maybe I'll ask, "Why is this? It seems a little funky. What's the history?" And they'll be like, "Yeah, it was built in a hurry, but it works. And so there hasn't been any churn. We don't have any issues with it, so we have just left it." And that has helped reinforce the idea that just because something could be improved doesn't mean it's worthwhile to improve it. Circling back to your original quest where you are looking to improve the process for merging and ensuring that CI stays green, I do like that you highlighted the fact that we do need to just be able to override settings. So that's something that has happened recently this week for me and my client work where we have had PRs that didn't have a green build because we have some flaky tests that we are actively working on. But we recognize that they're flaky, and we don't want that to block us. I'm still shipping work. So I really appreciate the consideration where we want to optimize so that everyone has an easy merging experience. We know things are green. It's trustworthy. But then we also have the ability to still say, "No, I am confident that I know what I'm doing here, and I want to merge it anyways, but thank you for the warning." CHRIS: And the constant pendulum swing of over-correcting in various directions I've experienced that. And as you said, in the back of my mind, I'm like, oh, I know that this setting I'm going to need a way to turn this setting off. So I want to make sure that, most importantly, I'm not the only one on the team who can turn that off because the day that I am away on vacation and the build is broken, and we have a critical bug that we need to fix, somebody else needs to be able to do that. So that's sort of the story in my head. At the same time, though, I've worked on so many teams where they're like, oh yeah, the build has been broken for seven weeks. We have a ticket in the backlog to fix that. And it's like, no, the build has to not be broken for that long. And so I agree with what you were saying of consulting has so usefully helped me hone where I fall on these various spectrums. But I do worry that I'm just constantly over-correcting in one direction or the other. I'm never actually at an optimum. I am just constantly whatever the most recent thing was, which is really impacting my thinking on this. And I try to not do that, but it's hard. STEPH: Oh yeah. I'm totally biased towards my most recent experiences, and whatever has caused me the most pain or success recently. I'm definitely skewed in that direction. CHRIS: Yeah, I definitely have the recency bias, and I try to have a holistic view of all of the things I've seen. There's actually a particular one that I don't want to pat myself on the back for because it's not a good thing. But currently, our test suite, when it runs, there's just a bunch of noise. There's a bunch of other stuff that gets printed out, like a bunch of it. And I'm reminded of a tweet from Kevin Newton, a friend of the show, and I just pulled it up here. "Oh, the lengths I will go to avoid warnings in my terminal, especially in the middle of my green dots. Don't touch my dots." It's a beautiful beauty. He actually has a handful about the green dots. And I feel this feel. When I run my test suite, I just want a sea of green dots. That's all I want to see. But right now, our test suite is just noise. It's so much noise. And I am very proud of...I feel like this is a growth moment for me where I've been like, you know what? That is not the thing to fix today. We can deal with some noise amongst the green dots for now. Someday, I'm just going to lose it, and I'm going to fix it, and it's going to come back to green dots. [chuckles] STEPH: That sounds like such a wonderful children's book or Dr. Seuss. Oh, the importance of green dots or, oh, the places green dots will take you. CHRIS: Don't touch my dots. [laughter] STEPH: Okay. Maybe a slightly aggressive Dr. Seuss, but I still really like it. CHRIS: A little more, yeah. STEPH: On that note of our love of green dots, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeee!!! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.