Screaming in the Cloud - Allowing Aspiration to Lead with Tom Totenberg

Episode Date: April 21, 2022

About TomTom enjoys being a bridge between people and technology. When he's not thinking about ways to make enterprise demos less boring, Tom enjoys spending time with his wife and dogs, reading, and gaming with friends.Links Referenced:LaunchDarkly: https://launchdarkly.comHeidi Waterhouse Twitter: https://twitter.com/wiredferret

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. SQL, and full-text search. Flexible JSON documents align to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document

database. Visit couchbase.com slash screaming in the cloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella. Make your data sing. This episode is sponsored by our friends at Revelo. Revelo is the Spanish word of the day and it's spelled R-E-V-E-L-O. It means I reveal. Now, have you tried to hire an engineer lately? I assure you it is significantly harder than it sounds. One of the things that Ravello has recognized is something I've been talking about for a while, specifically that while talent is evenly distributed, opportunity is absolutely not.

They're exposing a new talent pool to basically those of us without a presence in Latin America via their platform. It's the largest tech talent marketplace in Latin America with over a million engineers in their network, which includes but isn't limited to talent in Mexico, Costa Rica, Brazil, and Argentina. Now, not only do they wind up spreading all of their talent on English ability as well as, you know, their engineering skills, but they go significantly beyond that. Some of the folks on their platform are hands down the most talented engineers that I've ever spoken to. Let's also not forget that Latin America has high time zone overlap with what we have here in the United States. So you can hire full-time remote engineers who share most of the

workday as your team. It's an end-to-end talent service. So you can find and hire engineers in Central and South America without having to worry about, frankly, the colossal pain of cross-border payroll and benefits and compliance because Revelo handles all of it. If you're hiring engineers, check out revelo.io slash screaming to get 20% off your first three months. That's R-E-V-E-L-O dot I-O slash screaming. Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's promoted episode is brought to us by our friends at LaunchDarkly. And it's always interesting when there's a promoted guest episode because they generally tend to send someone who has a story to tell in different ways.

Sometimes they send me customers of theirs. Other times they send me executives. And for this episode, they have sent me Tom Totenberg, who's a senior solutions engineer at LaunchDarkly. Tom, thank you for drawing the short straw. It's appreciated. Anytime. Thank you so much for having me, Corey. So you're a senior solutions engineer, which in many different companies is interpreted differently. But one of the current themes that tends to pop up is often that that is a different way of saying sales engineer, because if you say sales, everyone hisses and recoils when you enter the conversation. Is that your experience or do you see your role radically differently?

Well, I used to be one of those people who did recoil when I heard the word sales. I was raised in a family where you didn't talk about finances. You know, that's considered to be faux pas. And when you hear the word sales, you immediately think of a car lot. But what I came to realize is that especially when we talk about cloud software or any sort of community where you start to run into the same people at conferences over and over and over again, turns out the good salespeople are the ones who actually try to form relationships and try to solve problems. And I realized that, oh, I like to work with those people. It's pretty exciting. It's nice to be aspirational about what people can do and bring in the technical chops to see if you can actually make it happen. So that's where I fit in. The way that I've always approached it has been rather different

because before I got into tech, I worked in sales a bunch of times and coming up from the, I guess, clawing your way up doing telesales, which is a polite way of describing back in the days before there were strong regulations against it, calling people at dinner to sell them credit cards. And what's worse is I was surprisingly effective at it for a kid who, like you, grew up in a family where we didn't talk about money. And it's easy to judge an industry by its worst examples. Another one of these would be recruiting, for example, when everyone talks about how terrible third-party recruiters are because they're referring to the ridiculous spray-and spray and pray model of just blasting out emails to everything that holds still long enough that meets a keyword. And yeah, I've also met some

recruiters that are transformative as far as the conversations you have with them go. But similar to that, with sales, it's, oh, well, you can't be any fun to talk to because I had a really bad experience buying a used car once and my credit was in the toilet. Yeah, exactly. And, you know, I had a similar experience with recruiters coming to LaunchDarkly. So not even talking about the product. I was a skeptic. I was happy where I was. But then as I started talking to more and more people here, I'm assuming you've read the book Accelerate. You probably had a hand in influencing part of it. I can neither confirm nor deny because stealing glory is something I only do very intentionally. Okay, excellent. Well,

I will intentionally let you have some of that glory for you then. But as I was reading that book, it reminded me again of part of why I joined LaunchDarkly. I was a skeptic and they convinced me through everyone that I talked to, just what a nice place it is and the great culture. It's safe to fail. It's safe to try stuff and build stuff. And then if it fails, that's okay. This is the place where that can happen. And we want to be able to continue to grow and try something new. That's again, getting back to the solutions engineer, sales engineer, part of it. How can we effectively convey this message and teach people about what it is that we do launch darkly or not in a way that makes them excited to see the possibilities of it? How can we effectively convey this message and teach people about what it is that we do, launch darkly or not, in a way that makes them excited to see the possibilities of it?

So yeah, it's really great when you get to work with those type of people and it absolutely shouldn't be influenced by the worst of them. Sometimes you need to find the right ones to give you a chance and get in the door to start having those conversations so you can make good decisions on your own, not just try to buy whatever someone's, whatever their initiative is or whatever their priority is, right? Once upon a time, when I first discovered LaunchDarkly, it was pretty easy to describe, but you folks did. Feature flags. For longtime listeners of the show, and I mean very longtime listeners of the show, your colleague Heidi Waterhouse was guest number one. So I've been talking to you folks about a variety of different things in a variety of different ways. But yeah, LaunchDarkly, oh, you do feature flags.

And over time, that message has changed somewhat into something I have a little bit of difficulty, to be perfectly honest with you, in pinning down. At the moment we are recording this, if I pull up LaunchDarkly.com, it says, fundamentally change how you deliver software. Innovate faster, deploy fearlessly, and make each release a masterpiece. And I look at the last release I pushed out, which wound up basically fixing a couple of typos there. And it's like, well, shit, is it going to make me sign my work? Because I'm kind of embarrassed by a lot of it.

So it's aspirational. I get it. But it also somehow occludes a little bit of meaning. What is it you'd say it is you do here? Oh, office space. Wonderful. Good reference. And also to take about 30 seconds back, Heidi Waterhouse, what a wonderful human.

Wired Ferret on Twitter. Please, please go look her up. She's got just always such wonderful things to say. So if you don't like Heidi Waterhouse, it is in your certainty. It is because you've not yet met her. She's wonderful. Yes, she is. So what is it we'd say we do here?

Well, when people think about feature flags or at this point now feature management, which is a broader scope, that's the term that we're using now. It's really talking about that last bit of software delivery, the last mile, the last leg, whatever, you know, when you're pushing the button and it's going to production. So, you know, a feature flag, if you ask someone five or 10 years ago, they might say, oh, it's a fancy if statement controlled by a config file or controlled by a database. But with a sort of modern architecture, with global delivery, instant response time, or fraction of a second response time, it's a lot more fundamental than that. That's why the word fundamental is there, because it comes down to psychological safety. It comes down to feeling good about your life every day. So whether it is that you're fixing a couple typos or if you're radically changing some backend functionality and trying out some new sort or search algorithm, a new API route

that you're not sure if it's going to work at scale, honestly, you shouldn't have to stay up at night. You shouldn't have to think about deploying on a weekend because you should be able to deploy half-baked code to production safely. You should be able to do all that. And that's honestly what we're all about. Now, there's some extra elements to it, feedback loops, experimentation, metrics to make sure that your releases are doing well and doing what you anticipated that they would do. But really, that's what it comes down to, is just feeling good about your work and making sure that if there is a fire, it's a small fire and the entire audience

isn't going to get part of the splash zone, right? We're making it just a little safer. Does that answer your question? Is that what you're getting at? Or am I still just speaking in the lingo? That gets it a lot closer. One of the breakthrough moments, of course, I picked it up from one of Heidi's talks,

is feature flags. Seems like a front-end developer thing, yada, yada, yada. And she said, historically, yeah, in some ways, in some cases, that's how it started. But think about it this way. Think about separating out configuration from your deploy process. And what would that mean?

What would that entail? And I look at my current things that I have put out there, and there is no staging environment. My feature branch is main. And what would that change? In my case, basically nothing. But that's okay, because I'm an irresponsible lunatic who should not be allowed near anything expensive, which is why I'm better at stateless things, because I know better than to take my aura near things like databases. Yeah. So I don't know how old you are, Corey, but back... I'm in my mid-30s, which enrages my spouse, who's slightly older,

because I'm turning 40 in July. But during the pandemic, as it has for many of us, the middle has expanded. There you go. Right. Exactly. Can neither confirm nor deny. You can only see me from about the mid-torso up, so you're not going to see whether I've expanded. But when we were in school doing group projects, we didn't have Google Docs. We couldn't see what other people were working on.

You say, hey, we've got to write this paper. Corey, you take the first section. I'll take the second section. We'll go and write and we'll try to squish it back together afterward. And it's always a huge pain in the ass, right? It's terrible. Nobody likes group projects. And so the old method of Git flow where we're creating these feature branches and trying to squish them back later and you work on that and you work on this thing and we can't see what each

other are doing, it all comes down to context switching. It is time away from work that you care about, time away from exciting or productive work that you actually get to see what you're doing and put it in a production and try it out. Nobody wants to deal with all the extra administrative overhead. And so, yeah, for you, when you've got your own trunk-based development, you know, it's all just main, that's okay. When we're talking about teams of 40, 50, 100, 1,000, suddenly it becomes a really big deal if you were to start to split off and get away from trunk-based development because there's so much extra work that goes into trying to squish all that work back together, right? So

nobody wants to do all the extra stuff that surrounds getting software out there. It's toil. It feels consistently like it is never standardized, so you always have to wind up rolling your own CI, CD thing for whatever it is, and forget between jobs.

Between different repositories and building things out is, oh, great, I get to reinvent the wheel some more. Either that or find somebody else's wheel that they put together and see if you can figure out where all those spokes lead off to. Is this secure? I don't know. How much stuff do you have running, even your personal stuff, that has more or less been copied around for a decade or so. During the pandemic, I finally decided, all right, you know what I'm doing? That's right. Being productive. We should fix that. I'm going to go ahead and redo my shell config, my ZSHRC from scratch because, you know, 15 years of technical debt later, a lot of the things I used to really needed to do don't really apply anymore. Let's make it prettier and let's make it faster.

And that was great and all, but just looking through it, it was almost like going back in time for weird shell aliases that I don't need anymore. It's, well, that was super handy when I ran a Ruby production environment, but I haven't done that in seven years and I haven't been in a specific scenario that one existed for since 2011.

So maybe I can turn that one off. Yeah, maybe. Maybe we can get rid of that one. When's the last time you ran npm install on something you were going to try out here and paid attention to the warnings that came up afterward? Hey, this one's deprecated. That one's deprecated. Well, let's see if it works first, and then we'll worry about that later, right? Exactly.

Security problems, whatever. It's a Lambda function. What do I care? Yeah, it's fine. Exactly. Yeah. So a lot of this is hypothetical for someone in my position, too, because I didn't ever get formal training as a software developer. I can copy and paste from Stack Overflow with the best of them, and there's all sorts of resources out there. But really, the people that we're talking to are the ones who actually live that day in, day out. And so I try to step

into their shoes and try to feel that pain, but it's tough. You have to be able to speak both languages and try to relate to people to see what are they actually running into, and is that something that we can help with? I don't know. The way that I tend to think about these things, and maybe it's accurate and maybe it's not, it's just no one shows up hoping to do a terrible job at work today, but we are constrained by a whole bunch of things that are imposed upon us. In some of the more mature environments, some of that is process. It's there for damn good reasons. Why can't I just push everything I come up with to production?

It's because we're a bank, genius. How about you think a little bit before you open your mouth? Other times it's because, well, I have to go and fight with the CICD system much yak shaving that has to go into building out anything that it's frustrating on some level, just all of the stuff you have to do just to get the scaffolding in place to write nonsense. I mean, back when they announced Lambda functions, it was in the future,

the only code you'll write is business logic. Yeah, well, I use a cropped on a Lambda here and it feels like most of the code I write is gluing all of the weird formats and interchanges together in different APIs. Not a lot of business logic in that, an awful lot of JSON finickiness. Yeah, I'm with you. And especially at scale, I still have a hard time wrapping my mind around how all of that extra translation is possibly going to give the same sort of performance and same sort of long-term usability, as opposed to something that just natively speaks the same language end-to-end. So yeah, I agree. There's still some evolution and some standardization

that still needs to happen, because otherwise we're going to end up with a lot of cruft at various points in the code to just, like you said, translate and make sure we're speaking the same language. Getting back to process, though, I spent a good chunk of my career working with companies that are, I would say, a little more conservative and talking to things like automotive companies or medical device manufacturers, very security-conscious, compliant places. And so agile is a four-letter word for them, right? Where going faster automatically means we're being dangerous because what would the change control board say? And so there's absolutely a mental shift that needs to happen on the business side. And the developers are

fighting this cultural battle just to try to say, hey, it's better if we can make small iterative changes. There is less risk if we can make small, more iterative changes. And convincing people who have never been exposed to software or know the ins and outs of what it takes to get something from my laptop to the cloud or production,

you know, wherever, then that's a battle that needs to be fought before you can even start thinking about the tooling. Living in the Midwest, there's still a lot of people having that conversation.

So you are clearly deep in the weeds of building and deploying things into production. You're clearly deep into the world of explaining various solutions to different folks. And clearly you have the obvious background for this. You majored in music. Specifically, you got a master's in it. So other than the obvious parallel of you continue to sing for your supper, how do you get from there to here? Luck and natural curiosity. Corey, right now you are sitting on the desk that is also housing my PC gaming computer, right? I've been building

computers just to play video games since I was a teenager. And that natural curiosity really came in handy because when I, like many people, realized that, oh no, the career choice that I made when I was 18 ended up being not the career choice that I wanted to pursue for the rest of my life, you have to be able to make a pivot, right? And start to apply some of the knowledge that you got towards some other industry. So like many folks who are now solutions engineers, there's no degree for solutions engineering. You can't go to school for it. Everyone comes from somewhere else. And so in my case, that just happened to be music

theory, which was all pedagogy and teaching and breaking down big complex pieces of music into one note at a time, doing analysis, figuring out what's going on underneath the hood. And all of those are transferable skills that go over to software, right? You open up some giant wall of spaghetti code and you have to start following the path and breaking it down because every piece is easy one node at a time. Every bit of code in theory is easy one line at a time

or one function at a time, one variable at a time. You can continue to break it down further and further, right? So it's all just taking the transferable skills that you may not see how they get transferred, but then bringing them over to share your unique perspective because of your background to wherever it is you're going. In my case, it was tech support, then training, and then solutions engineering. There's a lot to be said for blending different disciplines. I think that there was, on the knots, at least, and you majored in a narrow list of things, as long as they're all computer science. And then you wind up going into the following type of role, because this is the pedigree we expect in everything. Soup the nuts is aligned around that background and experience, where you would find

people who would be working in the industry for 10 years and they would bomb the interview because it turns out that most of us don't spend our days implementing quicksort on whiteboards or doing other algorithmic based problems. We're mostly pushing pixels around a screen, hoping to make ourselves slightly happier than we were. Here we are. And that becomes a strange world. It becomes a really, really weird moment. And I don't know what the answer is for fixing any of that. And that presents additional opportunities, additional angles to solve whatever problems you're encountering. And so you're right. We shouldn't be looking for people who have the specific background that we are looking for. How it's described in Accelerate, can you tell that I read it recently? We should be looking for capabilities, right?

Are you capable? Do you have the capacity to do the problem-solving, the logic? And, of course, some education or experience to prove that. But are you the sort of person who will be able to tackle this challenge? It doesn't matter, right, if you've handled that specific thing before, because if you've handled that specific thing before, you're probably going to implement it the same way again, even if that's not the appropriate solution this time. So scrap that and say, let's find the right people. Let's find people who can come up with creative solutions to the problems that we're facing. Think about ways to approach it

that haven't been done before. Of course, don't throw out everything with the bath water out with the baby or whatever that is, but come in with some fresh perspectives and get it done. I really wish that there was more of an acceptance for that. And I think we're getting there. I really do, But it takes time. And it does pay dividends.

I mean, that's something I want to talk to you about. I love the sound of my own voice. I wouldn't have two podcasts if I didn't. The counter argument, though, is that there's an awful lot of things that get, you know, challenging. Especially when, unlike in a conference setting, most people consider it rude to get up and walk out halfway through. When we're talking and presenting information to people during a pandemic situation, well, that changes a lot. What do you do to retain people's interest? Sure. So COVID really did a number on anyone who needs to present information or teach.

I mean, just ask the millions of elementary, middle school, and high schoolers out there, even the college kids. Everyone who's still getting their education suddenly had to switch to remote learning. Same thing in the professional world. If you are doing trainings, if you're doing implementation, if you're doing demos, if you're trying to convey information to a new audience, it is so easy to get distracted at the computer. I know this firsthand. I'm one of those people where if I'm sitting in an airport lobby and there's a TV on, my eyes are glued to that screen. That's me. I have a hard time looking away. And the same thing happens to anyone who is

on the receiving end of any sort of information sharing, right? You've got Slack blowing you up. You've got email that's pinging you, and that's bound to be more interesting than whatever the person on the screen is saying. And so I felt that very acutely in my job. And there's a couple of good strategies around it, right, which is we need to be able to make things interactive. We shouldn't be monologuing like I am doing to you right now, Corey. We shouldn't be just going off on tangents that are completely irrelevant to whoever's listening. And there's ways to make it more interactive.

I don't know if you are familiar or how much you have watched Twitch, but in my mind, the same sorts of techniques, the same sorts of interactivity that Twitch streamers are doing, we should absolutely be bringing that to the business world. If they can keep the attention of 12-year-olds for hours at a time, why can we not capture the attention of business professionals for an hour-long meeting? Right? There's all sorts of techniques and learnings that we can do there. The problem I keep running into is if you go stumbling down that pathway into the Twitch streaming model, I found it awkward, the few experiments I've made with it, because unless

I have a whole presentation ready to go and I'm monologuing the whole time, the interactive part with the delay built in and a lot of um and ah and waiting and not really knowing how it's going to play out and go and see to the pants, it gets a little challenging in some respects. Yeah, that's fair. Sometimes it can be challenging. It's risky, but it's also higher reward because if you are monologuing the entire time, who's to say that halfway through the content that you are presenting is content that they want to actually hear, right? Obviously, we need to start from some sort of fundamental place and set the stage, say, this is the agenda. But at some point, we need to get feedback similar to software development. We need to know if the direction that we are going is the direction they also want to go. Otherwise,

we start diverging at minute 10, and by minute 60, we have presented nothing at all that they actually want to see or want to learn about. So it's so critical to get that sort of feedback and be able to incorporate it in some way, right? Whether that way is something that you're prepared to directly address, or if it's something that says,

hey, we're not on the same page, let's make sure this is actually a good use of time instead of me pretending and listening to myself talk and not taking you into account, that's critical, right? And that is just as important, even if it feels worse in the moment. This episode is sponsored in part by our friends at Chaos Search. You could run Elastic Search or Elastic Cloud or OpenSearch, as they're calling it now, or a self-hosted Elk stack. But why? Chaos Search gives you the same API you've come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks,

for app performance monitoring, cybersecurity. If you're using Elasticsearch, consider not running Elasticsearch. They're also available now in the AWS Marketplace. If you'd prefer not to go direct and have half of whatever you pay them count toward your EDP commitment, discover what companies like Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm yet again. From where I sit, one of the many, many, many problems confronting us is that there's this belief that everyone is like we are. I think that's something fundamental, where we all learn in different ways. I have never been, for example, this sounds heretical sitting here saying it, but why not? I'm not a big podcast person. I don't listen to them

very often just because it's such a different way of consuming information. I think there are strong accessibility reasons for there to be transcripts of podcasts. That's why every 300 and however many odd episodes that this one winds up being the sequence in, every single one of them has a transcript attached to it done by a human. And there's a reason for that. Not just the accessibility wins, which are obvious, but the fact that I can absorb that information way more quickly if I need to review something or consume that. And I assume other people are like me. They're not. Other people prefer to listen to things than to read them, or to watch a video instead of listening, or to build something themselves, or to go through a formal curriculum in order to learn something. I mean, I'm sitting here with an eighth grade education myself. I take a different view to

how I go about learning things. And it works for me, but assuming that other people learn the same way that I do will be awesome for a small minority of people and disastrous for everyone else. So maybe, just a thought here, we shouldn't pattern society after what works for me. Absolutely. There is a multiple intelligence theory out there, something they teach you when you're going to be a teacher, which is that people learn in different ways. You don't judge a fish by its ability to climb a tree. We all learn in different ways. And getting back to what we were talking about, about presenting effectively, there needs to be multiple approaches to how those people can consume information. I know we're not recording video, but for everyone listening to

this, I am waving my hands all over the place because I am a highly visual learner, but you must be able to accept that other people are relying more on the auditory experience. Other people need to be able to read that, like you said, with the accessibility, or even get their hands on it and interact with it in some way, whether that is control effing your way through the transcript or command F, I'm sorry, Mac users. I am also on a Mac. But we need to make sure that the information is ready to be consumed in some way that allows people to be successful. It's ridiculous to think that everyone is wired to be able to sit in front of a computer or in a little cubicle for eight hours a day, five days a week,

and be able to retain concentration and productivity that entire time. Absolutely not. We should be recording everything, allowing people to come back and consume it in small chunks, consume it in different formats, consume it in the way that is most effective to them.

And the onus for that is on the person presenting. It is not on the consumer. I make it a point to make what I am doing accessible to the people I am trying to reach, not to me. And sometimes I'm slacking. For example, we're not recording video today. So whenever it looks like I'm not paying attention to you and staring off to the side like, oh God, he's boring. No, I have the same thing mirrored on both of my screens. I just prefer to look at the thing that is large and easy to read rather than the teleprompter, which is a nine inch screen that is about four feet in front of my face. It's one of those easier for me type of things. On video, it looks completely off, so I don't do it, but I'm, oh good, I get to take the luxury of not

having to be presentable on camera in quite the same way. But when I'm doing a video scenario, I absolutely make it a point to not do that because it is off-putting to the people I'm trying to reach. In this case, I'm not trying to reach you. I already have. This is a promoted guest episode. You're trying to reach the audience. And I believe from what I can tell, you're succeeding. So please keep at it. Oh, you bet. Well, thank you. You know this already, but this is the very first podcast I've ever been a guest on. So thank you also for making it such a welcoming place. For what it's worth, I was not offended and didn't think you weren't listening. Obviously, we're having a great time here. But yeah, it's something that, especially in the software space, people need to be aware of because everyone's job is, whether you like it or not, here's a controversial statement, everyone's job is sales.

Are you selling your good ideas for your product to your boss, to your product manager? Are you able to communicate with marketing to effectively say, hey, this is what I in tech support am seeing. This is what people are coming to me with. This is what they care about. You are always selling your own performance to your boss, to your customers, to other departments where you work, to your spouse, to everybody you interact with. We're all selling ourselves all the time. And all of that is really just communication. It's really just making sure you're able to meet people where they are and effectively bridge your point of view with theirs to make sure that we're on the same page and we're able to communicate well. That's so especially important now that we're all remote. Just so you don't think this is too friendly of a place, let's go ahead and finish up the episode with a personal attack.

Before you wound up working at LaunchDarkly, you were at Perforce. What's up with that? I mean, that seems like an awfully big company to cater to its single customer, who is, of course, J. Paul Reed. Yeah, but well, Perforce is a wonderful place. I have nothing but love for Perforce, but it is a very different landscape

than LaunchDarkly, certainly. When I joined Perforce, I was supporting a product called Helix ALM, which they're still headquartered. Perforce is I was supporting a product called Helix ALM, which they're still headquartered. Perforce is headquartered here in Minneapolis. I just saw some Perforce folks last week. It truly is a great place, and it was the place that introduced me to so many DevOps

concepts. But that's a fair statement. Perforce has been around for a while. It has grown by acquisition over the past several years. And they're putting together new offerings by mixing old offerings together in a way that satisfies more modern needs. Things like virtual production and game development and trying to package this up in a way that you can then have a game development environment in a box, right? And so there's a lot of things to be said for that, but it very much is a different landscape than a smaller cloud native company, which it's its own learning curve,

let me tell you. But truly, yeah, to your point, Perforce, there's a lot more complexity to the products themselves because they've been around for a little bit longer. Solid, solid products, but there's a lot going on there. And it's a lot harder to learn them right up front, as opposed to something like LaunchDarkly, which seems simple on the surface, and you can get started with some of the easy concepts and implementation in like an hour. But then as you start digging deeper, suddenly there's a lot more complexity hidden underneath the surface, and just in terms of how this is set up and some of those edge cases. I have to say for the backstory, for those who

are unfamiliar, is I live about four miles away from J. Paul Reed, who is a known entity in reliability engineering in the DevOps space, has been for a long time. So to meet him, of course, I had to fly to Israel. And he was keynoting DevOps Days Tel Aviv. And I had not encountered him before. It was, this is awesome. I love his talk. It was fun. And then I gave a talk a little while later called Terrible Ideas in Git. And he's sitting there just glaring at me, holding his water bottle that is a branded Perforce thing. And it's like, do you work there? He's like, no, I just love Perforce. It's like, congratulations, having used it. I think you might be the only one. I kid, I kid.

It was great at a lot of different things. It was not quite what I needed when I needed it to be, but that's okay. It's gotten better and everyone else is not me, as we've discussed, people of different use cases. And that started a very long running joke that J. Paul Reed is the entirety of the Perforce customer base.

Yeah, and to your point, there's definitely use cases. You're talking about Perforce version control or Helix core. Back in those days, I don't believe it was differentiated. It was just called Perforce. Exactly right. But yeah, as Perforce has gotten bigger, now there's different product lines, you name it. But yeah, some of those modern scalable problems, being able to handle giant binary files, being able to do automatic edge replication for globally distributed teams so that when your team in APAC comes online, they're not having to spend the first two hours of their day just getting the most recent changes from the team in the Americas and Europe. Those are problems that Perforce is absolutely solving that are out there, but it's

not problems that everybody faces. And, you know, there's, just like everybody else, we're navigating the landscape and trying to find out where the product actually fits and how it needs to evolve. And I really do wish you well on it. I think there's going to be an awful lot of future stories where there is this integration. I mean, you'd say, oh, well, what are you wishing me well for? I don't work there anymore. But, yeah, but isn't that kind of what we're talking about on some level, of building out

things that are easy, that are more streamlined, that are opinionated in the right ways, I suppose. And honestly, that's the thing that I found so compelling about LaunchDarkly. I have a hard time imagining I would build anything for production use that didn't feature it these days if I were, you know, better at computers. Sure, yeah. Well, we do have our opinions on how some things should work, right? Where the data is exposed. Because with any feature flagging system or feature management, LaunchDarkly included, you've got a set of rules, i.e. who should see this? Where is it turned on? Where

is it turned off? Who in your audience or user base should be able to see these features. That's the rules engine side of it. And on the other side, you've got the context to decide, well, you know, I'm Corey, I'm logging in, I'm in my mid 30s. And I know all this information about Corey. And those rules need to then be able to determine whether something should be on or off or which experience Corey gets. So we are very opinionated over the architecture, right? And where that evaluation actually happens and how that data is exposed or where that's exposed, because those two halves need to meet. And both halves have the potential to be extremely sensitive. If I'm targeting based off of a list of 10,000 of my premium users, email addresses,

I should not be exposing that list of 10,000 email addresses to a web browser or a mobile phone. That's highly insecure and inefficient. That's a large amount of text to send over 10,000 email addresses. And so when we're thinking about things like page load times and people being able to push F12 to inspect the page, absolutely not. We shouldn't be exposing that there. At the same time, it's a scary prospect to say, hey, I'm going to send personal information about Corey over to some third-party service, some edge worker that's going to decide whether Corey should see a feature or not. So there's definitely architectural considerations and different use cases, but that's something that we think through all the time and make sure it is secure. There's a reason I'm going to put on my

sales engineer hat here, which is to say that there is a reason that the Center for Medicare and Medicaid Services is our sponsor for FedRAMP moderate certification in process right now, expected to be completed mid-2022. I don't know, but anybody who is unfamiliar with that, if you've ever had to go through high trust certification, you know, any of these compliances to make your regulators happy, you know that FedRAMP is so incredibly stringent. And that comes down to evaluating where are we exposing the data? Who gets to see that? Is security built in and innate into the architecture? Is that something that's been thought through? I went so far afield from the original point that you made,

but I agree, right? We've got to be opinionated about some things while still providing the freedom to use it in a way that is actually useful to you and we're not, you know, putting up guardrails that mean that you've got such a narrow set of use cases. I'd like to hope, maybe I'm wrong on this, that it gets easier the more that we wind up doing these things because I don't think that it necessarily has been easy enough for an awful lot of us. When you say it, what do you mean? All of it. That's the best part. I suppose the easy parts of working on computers, which I guess might be typing if you learn it early enough. Sure. Yeah. Mario teaches typing or Starcraft taught me how to type quickly. You can't type slowly or else your expansion is going to get destroyed. No. So for someone who got their formal education in music or for someone with an eighth grade education, I agree.

There need to be resources out there. And there are not every single Stack Overflow post with a question that's been asked has the response. That's a dumb question. There are some out there. There's definitely a community or a group of folks who think that there is a correct way to do things. And that if you're asking a question that it's a dumb question. It really isn't.

It's getting back to the diverse backgrounds and diverse schools of thought that are coming in. We don't know where someone is coming from that led them to that question without the context. And so we need to continue providing resources to folks to make it easy to self-enable and continue abstracting away the machine code parts of it in friendlier and friendlier ways. I love that there are services like Squarespace out there now, right, that allow anybody to make a website. You don't have to have a degree in computer science to spin something up and share it with the world on the web. We're going to continue to see that type of abstraction, that type of on-ramp for folks, and I'm excited to be a part of it.

I really look forward to it. I'm curious to see what happens next for you, especially as you continue, you being the corporate you here. It's like the understood you or the royal you. This is the corporate you. Continue to refine the story of what it is LaunchDarkly does, where you start, where you stop, and how that winds up playing out. Yeah, you bet. Well, in the meantime,

I'm going to continue playing with things like GitHub Copilot, see how much I can autofill and see which paths that takes me down. Oh, I've been using it for a while. It's great. Just tab complete my entire life. It's amazing.

Oh, yeah, absolutely. Other people's secrets start working great. That makes my, you know, it's built way lower when I use someone else's keys, but that's neither here nor there. Yeah, exactly. That's a next step of doing that NPM install That makes my, you know, it's way lower when I use someone else's keys, but that's neither here nor there. Yeah, exactly. That's the next step of doing that NPM install or, you know, bringing in somebody else's tools that they've already made.

Yeah, just a couple weeks ago, I was playing around with it, and I typed in two lines. I imported the LaunchDarkly SDK and the configuration for the LaunchDarkly SDK, and then I just let it autofill whatever it wanted. It came out with about 100 lines of something or other. And not all of it made sense, but hey, I saw where the thought process was. It was pretty cool to see. I really want to thank you for spending as much time and energy as you have talking about how you see the world and where you folks are going. If people want to learn more, where's the best place to find you? At launchdarkly.com. Of course, any other various different booths, DevOps days, we're at reInvent,

we're at QCon right now, we're at all sorts of places. So come stop by, say hi, get a demo. Maybe we'll talk. Excellent. We will be tossing links to that into the show notes. Thanks so much for your time. I really appreciate it.

Corey, thank you. Tom Totenberg, Senior Solutions Engineer at LaunchDarkly. I really appreciate it. Corey, thank you. Tom Totenberg, Senior Solutions Engineer at LaunchDarkly. 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 and insulting comment, and then I'll sing it to you. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying.

The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. This has been a humble pod production stay humble