Software Huddle - Holiday Special!

Episode Date: December 26, 2023

In this special end of the year clips episode of Software Huddle, we took some time to highlight some of our favorite clips from our interviews since we launched the show back in August. Software Huddle: https://twitter.com/SoftwareHuddle Alex: https://twitter.com/alexbdebrie Sean: https://twitter.com/seanfalconer

Hello and welcome to Software Huddle. I'm Sean Falkner and I'm here with my co-host Alex Debris for a special end of the year clips episode of Software Huddle. Alex and I are going to take some time today to highlight some of our favorite clips from our interviews since we launched the show back in August. But before we get into all that, Alex, how are you doing? You know, I'm doing well, you know, safely back from reInvent and all the fun that we had there and different things like that. And now for me, it always seems like reInvent is the end of the year for me. And I just sort of coast into the holidays and gear off with the new year. So yeah, excited to, you know, look back at our first year of Software Huddle, have our last episode of the year here and

see what we've been doing here. Yeah, awesome. Yeah, we both survived reInvent. And then I flew immediately to Paris for the week, survived that. And then I basically died a little bit after that. I was fighting a cold and I felt kind of terrible. But I'm now in full recovery and feeling good, ready to celebrate the holidays. Yeah, you're way more adventurous than me. I need more recovery time than that. But you're just always jetting all over the place.

So that's great. Yeah, it gives me energy until it doesn't essentially fall off a cliff at some point. But also one cool thing about re-event, probably maybe not everybody knows this, but we'd never met in person until we actually met up at re-event. So that was fun. It was fun. Yeah, good to put a real live face to the name, not just a virtual one. So yeah, good to catch up and meet for the first time.

Yeah, now you know I'm not just a virtual one. So yeah, good to catch up and meet for the first time. Yeah, now you know I'm not just a deepfake video. And we also met one of our recent guests, Merit Bear, there as well, had shared some hot pot with her. So that was really fun to be able to do that too. Yeah, and you were meeting with AWS Royalty, Jeff Barr. He called you out on LinkedIn and everything. So yeah, you had a big reinvent. Yeah, that's the peak.

It's all downhill now. Yeah. Yeah, that was awesome to, that's the peak. It's all downhill now. Yeah. Yeah. That was awesome. Uh, to, to be able to spend like half an hour or so talking to Jeff and then actually have him remember enough of that conversation to post about it on LinkedIn. So that was awesome. Yeah. Yeah. Yeah. It's always a good time re-invent, like just so many people there, like, you know, you and I have never met, but just a lot of people I talked to all year. And then finally we're all in one place. I'm just going to hang out with people and see what they're up to. So great time. Yeah. Tons of fun. All right. Alex, you want to set up the first clip here? Yeah, sure. So my first one, this was my first episode I recorded for Software Huddle. This was

with Sam Lambert from PlanetScale. Super interesting guy. PlanetScale is doing some cool stuff. And I thought it was a fun episode just talking about technical stuff with MySQL and PlanetScale and just databases, generally all that stuff. This clip was different and valuable in a different way, right? We're talking about role changes as he sort of progresses up through a company. He was early at GitHub and sort of worked his way up the ranks there. And now is the CEO at PlanetScale. And just like, what does that look like in terms of staying technically sharp and what changes about your role? Also, I just think PlanetScale does a really good job on execution and doing everything really well. And how do you maintain that sort of

high bar? So it was fun just talking about his role and maintaining that sort of standard of excellence at PlanetScale. Awesome. Let's roll the clip. When you talk about experts leading experts, as you've continued to climb up the executive ladder, like VP Eng and then Chief Product and Chief Executive, how do you still stay sharp and technical? Do you do some hands-on stuff, even if it's in your spare time? Do you just keep up with design docs? Or do you just know your spots more and where you are leading the experts? You're an expert leading the experts. Yeah, I would hate to horrify our engineering team by submitting any of my work to...

I'm not... So here's the model ways. So I know I try and acknowledge the things I don't know, right? Like, can I do not spend time in the weeds technically, as much as I could do at plant scale, because I have other things I should do, right? There's, we're here to build a business or websites or just automation for my home is one thing I mess around with. So I still write code at least once a week. But you got to be careful. There's another profile of like I was technical once style leaders that were like, I was an engineer once. And they try and like write code for their team. And it just becomes like this embarrassing.

I try not to do that. I also just hold technical conversations. Um, like our VP of engineering is outstanding where he communicates, um, the changes we're making and you can just track along. Once you know this stuff, once you kind of track along with the changes, you understand the trade-offs um and the other thing is the role i have to play um with the organization is understanding the the very technical things we have to do for a database then we have to translate that into design and

visual design and marketing and brand and because i'm always in the kind of middle of that i very much appreciate brand i very much appreciate our marketing and and beautiful design and again that only comes from it being cared about at the top because otherwise very technical companies you can tell that their designers are getting steamrolled um and and so you have to hold all of those things in balance and appreciate all of those things which means you think about them a lot and you learn about them a lot is that something you've always had had natural like i i agree like planet scale has really good design for an infrastructure company and if you told me like hey former my sequel dba is like their ceo i i just like wouldn't expect great design or or like no offense to you but like you really have a great design aesthetic and like how

much is that something you've had a talent for that you've picked up over the years or you just like are able to find great designers that can that can help pull that because i've worked at some technical companies that did not have uh that sort of that sort of feeling I've always appreciated design and style ever since I was young uh I did best at art at school I've loved art my house is absolutely teeming with art I've always loved and appreciate aesthetics and style and fashion um even though nowadays all i wear is black t-shirts and a database hat but i do um i've always had a strong that is great fashion right yeah maybe maybe but i've always just always appreciated like i you know i love bags for example a ridiculous collection of bags and shoes and all these various things i just love

aesthetic things things that you know there's things like the iphone right which is just like a technical masterpiece presented so simply i've got this obsession with power and simplicity and how hard it is to present incredibly powerful things simply and it's always just fascinated me and then github fully solidified this for me that it is possible to build a thriving and exciting company while caring about aesthetic the early engineers and designers of github had the most perfect taste i don't think they could quantify what that magic was because you don't have to when you have taste um and and seeing the lengths that we went to to not ship things that were ugly or shoddy was truly inspiring and

we carried that over to planet scale but it's something we all really care about and it's also again why you have to be careful with the talent bar because you can't democratize taste you just that's why i argue with people on the internet it's just pointless because they just don't see it the way you see it right you just have to hold it in front of their faces like is this ugly or bad yes or no right and and and some people want to hide their product in i mean i'm just very proud of plan scale we we can take you to petabytes of data and you'll never have to write yaml i mean that's some like the things people put their users through is abysmal um and we just try really hard not to do that and over the long run that that really pays off and it's put my

sequel in places that it historically never would have been you know i see well first of all i see our website like very often you see these like top 10 best websites or technical websites it's like linear us notion stripe github you're just like immensely proud and and and we have a technology that is most relevant was started off as being most relevant to giant or enterprises with giant scaling problems. And the fact now we've got hundreds of thousands of developers using the product for the most ripping hot, cool projects is because we delivered incredible developer experience and taste and style. And that's all changed. It's how things are done nowadays. All right. So yeah, I just, you know, I love that interview. I love that clip. I think it's interesting just seeing Sam sort of balance the problem that you see from a lot of people

where maybe it's like the first engineer or someone that is very technical, but now goes into that C-suite and they want to like keep their fingers in the pie too much and sort of like end up blocking things or just like creating a mess and things. And I think just the way he's realizing like, hey, I still need to stay think just the way he's realizing like, hey, I still need to stay technical, partly because he loves it, but also because it helps them translate it to brand and marketing and talking to customers and all that sort of thing.

I think that trade-off is pretty interesting. And just like a difficult one that I haven't seen other companies manage super well in the past. Yeah, I think it's a hard transition for lots of people who are really technical to move into those leadership positions. Even people who don't necessarily reach the height of CEO, but when you're moving even from an IC to a manager role, or from an IC engineer to a product

management role or something like that, I think a lot of the classic missteps is just like, oh, I need to be in there bit twiddling every single thing that's coming out. But you're never going to be able to scale beyond a certain level. It's like the engineer's form of micromanagement. It's still like, I need to be in there, hands on keyboard, coding, when you're trying to actually make a team successful and scale an organization and stuff. And you're just never ever going to be able to do that if you're getting in like actually make a team successful and scale an organization and stuff. And you're just never, ever going to be able to do that. If you're kind of getting in your own way of your team being successful. Yep. It makes me think too, of just like my future. Cause I'm like, you know, in 30 years, am I still going to be programming? I don't know.

But then it's also just like, when I do get a programming thing and I get to just like sit down and work on that uninterrupted for four, eight hours at a time, you just like get that, that love of it and how fun it is to solve that problem. It's hard to give that up. But also you realize you want to be doing different higher level or just different things. And balancing that is tricky for myself. And I can imagine as you're moving up to leadership at a company, it's difficult in the same way. Yeah. I've certainly struggled with that in parts of my career as well, especially when I stepped into basically being the CTO and a founder right out of graduate school. So most of my pure IC engineering work was done in conjunction with being in school.

So I'd only worked for eight-month stints or year stint part-time and stuff like that. So it was a tough transition to simply be managing people. And to be honest, I had no idea what I was doing. And you learn a lot of harsh lessons along the way there. I love the line that he said about how you can't democratize taste. And I really love a lot of his takes. Some of the things I remember from his interview was around, if you want to build essentially exceptional companies, you need exceptional people. And I always keep that in mind also with the teams I've built, or especially working in the startup space. If you want to build a snowflake, Salesforce, these types of companies, these marquee companies, once-in-a-generation companies, the bar is really high.

And you have to understand that as a leader and also understand that as someone entering the organization and make sure that you're keeping that bar. I think that's one of the really hard parts about a startup. It's not necessarily just even all the stuff around trying to find product market fit and figure out your go-to-market and stuff. It's maintaining that culture and that high level of excellence and setting that expectation and sometimes having to make like brutal decisions or like at least, you know, feels like brutal decisions of, you know, letting people go when it isn't a fit or they're not able to meet the mark. Yeah, absolutely. Cause there's just like a huge difference from when you're working with people that you trust and, and just like, you know,

can count on to do really good work all the time versus people that feel like they're just sort of punching the clock and just like it changes how you approach your work and it just it can really affect the whole team and yeah i love how planet scale i think they execute on like in every area at a very high level and you can just tell that like that that cultural quality very high hiring bar but just like very high expectations for themselves and like what it is and i love to see that from Yeah. And it's true. I think if you want to create a premium brand, you have to have that feeling across the entire company so that people aren't just putting out crap, essentially. And you need the gatekeeper, but you also need people to understand and be responsible for what their work is. All right. Well, next up, we have Bob Buglia,

veteran of Microsoft to 20 plus years, ex-CEO of Snowflake. And he was basically there from pre-revenue to nearly going public. I absolutely love this interview. This is probably the highlight of my podcasting career.

And in terms of the clip, what we talk about there was, I kind of set this thing up where I wanted to get Bob's take on difficult leaders and his experience working with people like Bill Gates and Steve Ballmer, sort of the height of Microsoft. I think a lot, especially Bill Gates has kind of become more of like a lovable grandpa as he's gotten older and stuff like that. But if you listen to some of the early Microsoft stories, it's pretty harsh. And so I wanted to kind of figure out how big of an asshole do you really need to be in order to run a big, successful company? So that's really the

setup here. Yeah. So if you go back to some of the early days at Microsoft and, of course, other companies like leaders, like I think Bill Gates, Steve Ballmer, Jeff Bezos, the list goes on and on. They're somewhat notoriously known for being somewhat difficult to deal with, at least back then. They're all difficult. I guess,

has things changed, I guess, is the bottom line? Or do you need to be that way in order to create these types of companies? It's a great question. First of all, the ones that are successful, they continue to have multiple sides to them, from what I can see. Most of these people are very, very driven and they have their idiosyncrasies as well.

Certainly contemporaries like Elon Musk are no less difficult than those guys were. But I don't know. I mean, I think the characteristic is very driven people that have objectives. And in some senses, they're, you know, they're going to focus on achieving those objectives. And that sometimes requires people to make difficult decisions and sometimes be difficult. Sometimes it helps because I really do think it helps people to push them to achieve more. On the other hand, I wouldn't say it's the way I would do things. I mean, I say all this, but that's not how I ran things, to be straight. I don't think people would say I did that. Although I could be difficult in reviews too if people are not prepared. Generally speaking, I don't think I was quite as difficult as some of those folks are. On the other hand, I'm not as successful as those folks were either.

I spent a lot of time thinking about this. How big of an asshole do you have to be in order to be super, super successful? It's a great question. Probably a little bit more than I am. Yeah. Well, you probably need, I mean, I think a lot of it comes down to you need at the very least to have a very high bar in terms of like the expectations that you're putting on people so that people are like forced to meet that bar.

And sometimes if they're not meeting that bar, you need to be, give them candid feedback. And a lot of times you don't have time to necessarily do that in the nicest way. So I think there's probably a balance there. You don't necessarily, I think it would be unfair to the success of these people to just say the correlation is be a giant asshole. And then you'll be,

you'll turn into Bill Gates, right? It's a little oversimplified. For sure. It takes more than that. However, the attribute does seem to come with the, come with the, those folks in my experience, in my experience. You know, the other thing I'll tell you is that, is that really brilliant technical people, while they don't tend to have the same assholishness as, as Stephen Bill and some of these others did, they, you know,

they are difficult too, in my experience. It's very rare working with these brilliant technical people that they're, that they have, you know, they're, they're just the same as everybody else. Let's put it that way. People who have these, these brilliant capabilities, you know, have their attributes that that comes through in their personality. And, and I've learned, you know, over time to really work with a wide variety of different people. And one of the most important things, I'll just say, is just trying to maintain relationships with people through all of that. That's, to me, something that's very important, that no matter what the issue is at hand,

the relationship with the person is actually almost certainly more important. All right, we're back. Well, how awesome was that? It was great. I still can't believe you got Bob on. And just what a fun interview. And yeah, this is a great clip to choose from. Yeah, he dropped so much gold in that interview.

Yeah, I hope at some point, you know, we're able to get him back. It's a little jarring watching the clip because I did that while I was at reInvent. So I have like a curtain background and stuff like that. It was funny to see his background. He's got a fossil behind him, and he's just like, what's going on here? I'm pretty sure that's a real fossil. Just guessing.

It's amazing. I also realized he has his book, The Data Preneurs, which I highly recommend to people. It is a really good read up in the background there as well. Some cool stuff. It's harder when you're talking to the person in the moment than necessarily well so some cool stuff uh being able to it's harder when you're talking to the person in the moment than necessarily capture all the information that their background uh so it's good to revisit these just uh to for my own information

yep exactly yeah i thought that was a a great clip and like it's interesting we talk about um you know assholes and things like that like but even just looking back in life um you know the teachers the coaches i had not necessarily like an asshole, but at least like very high standards, which is something that he was talking about too. Like, you know, you look back fondly on those times. I think that's like the most growth you have is when you have those people sort of pushing you towards doing better and having a vision and really aiming towards it and not just settling for good enough. So like, I don't know. I still feel inspired from those things when I see those. Yeah. I find myself as well. I respond, I think, to that kind of leadership. It's not for everybody, but also thinking back, one of the best hockey teams I

played on when I was a kid was we had this guy that was the coach. He was an ex-military guy. And he ran, I mean, we were like 10 years old, but he ran a tight ship, you know, like you're in bad at a certain time, but we, we also, you know, you couldn't sort of argue with the results of what we saw. And then the next year we basically had the same team, but we had a completely different coach and coaching style. And it was a lot more like, you know, the guy wanted to be, you know,

every, every kid's like best friend. And, you know, we were kind of terrible. So like, so I don't know, the results speak for itself in some ways. It is interesting at those formative stages, like how big, how big of a difference you can make. And it's funny, you come out of that and like, you feel close with your teammates. I don't know, sometimes you don't feel the greatest towards the coach itself at that point. But like, you know, eventually you probably look back fondly depending on, I guess, exactly the, you know, whether, whether he was an asshole or just strict, you know, but like, yeah, I just think that's like a great way to grow is to have someone that can lead you and really push you beyond what you think you're capable of.

Yeah. I mean, I think there's, there's definitely a balance between, like essentially going back to the Sam Lambert conversation as well as like, you need to set this high bar and you need to make sure people are you know hitting that bar and they understand when they're not and then but there's different sort of levels of how you could communicate that thing so i think for myself i i definitely have like a little bit softer touch i'm probably more in the bob moogle camp than the elon musk camp but i'm uh also you know not nearly as successful as any of those people so yeah i know i you know i feel the same thing with my kids, too.

I'm like, am I too easy on them? Am I like not getting enough out of them or whatever? But it's just like, you know, it's not my personality. It sounds like not quite yours either. But it is interesting like what you can get out of people if you push them. Yeah, you need to start setting a higher standard in your child's performance. Exactly right. Come on, play that piano, practice that violin, whatever it is. Yeah, exactly. All right. So next is a clip from

my conversation with Edis Chernova. He's the CEO and co-founder of Nucleus. Edis started Nucleus and got into Y Combinator all while working as a product lead for the company I work for, Skyflow, which is a Series B startup. So it was a lot about his journey through the first year of being a CEO that I thought was really interesting for anybody who is thinking about starting a company. And in the clip, you'll hear Elvis's response to me asking about trying to balance doing a full-time job while also building and launching a company, which is kind of a crazy thing to try to go through. You started the early ideas and the early prototyping while also essentially working as a full-time product manager. And it's not like you had some low effort, low responsibility job.

You're a product lead at a fast-growing startup. So how did you kind of balance starting a company with leading a full-time job? Yeah. I mean, I think, um, part of it was just, just the hours, honestly, I don't know if there's a, there's a way around it. Um, you know, it was working at Skyflow with, uh, with you and the team for the majority of the day. And I think what was interesting was like, we had, you know, a big team offshore. Um, and, and so like the hours are always interesting because we had like

the morning hours, then you have the nighttime hours to sync with our other team. Um, so trying to find, you know, maybe an hour or two during the week to talk about it, um, with Nick and anybody else I wanted to have a call with, um, but really is spending the weekends and just kind of dedicating myself and saying like, hey, this is something I'm really interested in. I want to see it through and I want to see where it takes me. So I'm willing to sacrifice, you know, the Saturdays and Sundays when I could be doing anything else. And so that was tough. You know, I did that for probably about seven months where pretty much every single weekend it was talking to Nick, talking to potential customers,

doing just discovery calls, doing some coding, doing some building. And then during the week, you know, going back and focusing on the day job. And there's, you know, lessons learned there. Like there's a part of me that says like, you know, was that the right thing to do? But it depends, right? It depends on your own personal situation. And for me, I just wasn't in a position where I could say, hey, I'm going to take six to 12 months off and just kind of like play around with some ideas and see where it goes. Yeah. I mean, I think that's a tough choice for anybody, especially living in the Bay Area.

It's not like the cost of living is low or anything like that. You need to be able to eat. But so you mentioned that you ended up going through Y Combinator. So why was that something that you were interested in doing? And what was the backup plan if you weren't accepted into YC? Yeah, I mean, you know, I think YC has obviously a brand, not just in sort of like Silicon Valley, San Francisco, the Bay Area, but also just generally in the world. And so I think for us, we had said, OK, well, one, it's a really good program and we're going to get, you know, hopefully really great guidance, which we did. But also there's, you know, there's something to be said about sort of like the signaling of going through YC and

being able to talk to investors, talk to potential customers. And so it felt like it was the right mix of we're still early enough just in our founder journey and our kind of like product and kind of problem journey that YC can help shape that. We're going to get a great sort of founder community, both with the people that are going through the batch with, but also previous YC founders. And then also it opens doors to be able to talk to investors and sort of have other sort of like connections and channels to go through. So it made sense to go through it. In terms of the backup plan, I think the backup plan was just continue working on it and just see where it takes us. If we didn't get in that batch, maybe try again and apply.

Otherwise, just kind of keep hammering on until it gets to a point where we say, hey, this is working. So great, we're going to go full time and try to get funding from investors. Or this isn't working. Let's go try something else. So, yeah, it was definitely plan A. But if it didn't work, it's not like we else. So yeah, it was definitely plan A, but if it didn't work, it's not like we're going to say, hey, we're just done with this. Like we were only in it to do YC.

All right, and we're back again. Yeah, I think, and this is like a really smart guy. I think actually, you know, I follow him on Twitter and I think he doesn't have much of a following, but he's definitely a good, he's a good follow. He's got lots of hot takes. So I encourage anybody out there to look him up. I like those hidden gem Twitter people where you're just like, oh, yeah, you're still under the radar enough that you can say some good stuff without getting it all fired and turned into a flame war.

So that's great. Yeah, he only has like 300 followers or something like that. But he's putting some good stuff out there. I really enjoy it. But one of the interesting things about post-sign interviews, they've actually pivoted Nucleus significantly. And in some ways, it's not even really a pivot. It's more like travel, essentially. The company's completely different in a lot of ways.

They're now a company called Neosync, or that's what the product is, and they're doing open-source test data ops. So we'll need to have them back at some point to kind of talk a little bit about that what did you think about his his notes about just like sacrificing with with hours and in times like that i guess like how does that match up with you know either your startup or when you were at google or now at skyflow like you know i think there's that work-life balance um topic that comes up a lot what do you how do you sort of come down on that yeah i think so i started my company while I was doing

my postdoc. I did basically have a full-time job as an academic. I was traveling to Geneva and Switzerland on a regular basis because I was working with the WHO at the time. It was a tricky balance. It was a lot of doing off hours or finding time even during the working day when I could work away on the product stuff. I was lucky that I had... My co-founder was pretty much full-time on the business at that time. So he could do a lot of the sales and the customer conversations and some of the fundraising stuff without my involvement. And most of the time, I was spending just hands on keyboard, building the initial version of the product. So that was really, really helpful. But I think it is tricky, but I think it's kind of a choice that you have to make, especially when you're building a company. There is startups. I think Skyflow does a pretty good

job of trying to emphasize work-life balance. But at the same time, if you're in a leadership role and startup, there's inevitably going to be times where you have to be willing to say, okay, well, I have to put time into this or I need to find time for this. That's outside of where you're working. It's really difficult, I think, to be super rigid. Like, hey, I work these hours and I'm kind of offline after that. At least for me, it doesn't work. It's just not realistic. But I've kind of always been that way with pretty much any job.

Like, I kind of, like, really dive into stuff. And it's, you know, maybe it's more about my personality than necessarily in the company. I just have a hard time kind of letting things go. Like, I don't really separate sort of work and life. To me, it's kind of all similar things. And I get a lot of enjoyment out of my work. So it's not something that I feel like it's, you of my work. So it's not something like that. I feel like it's a, you know,

like a drain from me or anything like that. I look forward to doing a lot of this stuff. So I think that also impacts sort of my approach to it. Yeah, I agree. I have the same sort of issue where I always pour a lot into my work. I think it's nice. Cause I mean,

I think at least like in sort of programming and things like that, like that's an enjoyable thing in and of itself. I like I find it like I don't need a lot of other hobbies. I think it's fun to just like solve a problem and and make something real and do something like that. So I think that's good. I also just think, you know, you're like between like when you're like age 20 to 35, you're like combination of stamina and just like ability to learn and all and and all that stuff works really well. Or if you put in some good time there, I think it really pays off later on. And you know, there are a lot of other things to consider as well. Like, but I just think

of, you know, my first couple programming jobs and things like that, and putting in a lot of extra time and what that sort of meant a little bit with like, my wife, my wife's understanding around some of that stuff. But now I think it's paid off in a lot of ways where we have a much more flexible life and, and things like that. So, you know, it's trade-offs and you have to think about, about that stuff. But I do think it can be beneficial, especially early in your career to really like put in that time, do the learning and, and, and you know, make those advances at that point.

Yeah. There's probably when you're young, there's generally not never going to be a time in your life where you have sort of more freedom in your schedule and your responsibilities to kind of like dive deep into things. I remember my first sort of engineering co-op job that I had in college. And like, I would work like every weekend because it wasn't because anyone was forcing me to. I just like loved it so much. Like, I love the opportunity to actually be doing something that was like working on a product. And it wasn't just like a school assignment or something like that. the opportunity to actually be doing something that was like working on a product um and it wasn't just like a school assignment or something like that so i think for me it was just such a

passion that i i just loved doing it so i was like i would do it i would have done it for free uh you know and i was happy to make a little bit of money doing it as well yeah don't tell your boss now but it's totally true like it's it's so much fun that you just like want to work on it anyway yeah Yeah, absolutely. All right, so let's go to the next clip here. All right, so next up we have Craig Dennis, longtime Twilio developer educator, who has since actually left Twilio.

So similar to Elvis, who has had a big transition in terms of his own company, Craig is off to whatever he is doing next. I'm not actually sure. I think he's taking a little break before he figures it out. But in the clip, I asked Craig about what is the right or wrong way to get started with coding? Essentially, should people have to suffer in the deep end of first, or should they essentially have a gentler introduction by cutting out things like the compiler and keeping things at a bit more of a high level to get started. So let's go to the clip.

What is your thoughts on... So I feel like in the world of developers kind of in the early stages learning how to code, there's often sort of two camps. There's this camp that I've heard Joel Spolsky talk about this, where it's essentially, you know, everyone should start out coding in, you know, C or C++. They need to feel the pain of not understanding, you know, memory error and having to dig into

the details to really understand the machine at its lowest level before, you know, graduating to sort of higher level, easier languages. And that's really like key basically you need to weed out the week early on and then there's another camp that's like hey let's be a little bit you know more inclusive let's start out well you know learn i don't know python or javascript something that's like a little you don't have to worry about compiler a little bit easier to to maybe get up and, doing that first program. And then, you know, when you're successful there, maybe you'll graduate into more complex tasks and so forth. What is your thoughts in terms of how someone, you know, navigates that world? Is there a right or wrong in this?

I would say if you can struggle through this, the C compiler, yeah, you're probably set up to do this. But if you go and you hit the C compiler, you're like, this is all the programming is and this is what it's about. And I'm not going to do this because this isn't for me. You're wrong. Right. That's your, that's not what it's about. Right. Like anymore. Right. Like I don't, I don't feel like that. That is, there are, there are parts of this that you, you could like, and you're cheating yourself, I think by making it in that, why not using the abstractions that exist? I even think that no code is a great way to come in and start playing around with codec ironically, right? Like, like understanding the structure and how, how things flow and what, what that's all about is an abstraction. No code has given

us. And you know, I think that there's like all this, there's a bunch of buzz around that, about that taking over our jobs and things like that. But I think really what happened is like, there's abstractions. And if you can use the abstraction and it doesn't, you don't need to dive deeper, I think you're going to be okay.

And like, you should dive deeper when you need to, right? If you run into something that you're not understanding, that's where you go and dive into it. But like really, if you're building, if you're, if you're working on a smaller site, if you're, if you're just getting started and you're working on a, on a website, you're working on just like a standard website that, that has displaying some dynamic data. Do you need to know how a compiler works?

Do you need to know what a compiler is? Like, I don't know. There's this, there's this level of like, that's, that's where I'm at. And like, I, I do see that as, um, you know, I think that there's, that's also the camp of like, you need a degree to, to do this, that, that, that camp exists. I don't know anymore. I think that it's almost like your're wasting. This is me talking. I'm not, the views I express might not be part of my employers. I think that you're almost at this point, four years dialed into a curriculum. There's no way that that's up to date. There's not like that.

That's just a plain truth. There's, there's no way that what you learn in there is still going to be up to date. And maybe that's where you're, you're jamming the compiler stuff. Cause that still is, is valid. Right. And that, that you are going to learn that stuff there. Are you going to enjoy that?

Are you going to actually be building the stuff that makes you think that I want to do this forever? Or are you going to get near the end of this and be like, ah, I don't know if this is for me. Wait, what's an API. And you're like a junior in college and you don't know what an API is yet on using a computer science thing. That's interesting. It's an interesting problem, right? So I'm almost on the other side.

I think like if I had to put myself in a camp, I would be like, do what's fun, right? Because this is a fun job if you can find it and you can find it. It will be there. That fun exists. And whether that's the problem that you're solving or the way that you're solving it, you're be there. That finally exists. And, and whether that's the problem that you're solving or the way that you're solving it, you're going to find it and explore.

I think, I think exploration is a huge in, in this, in this world. Yeah. Yeah. I think that a lot of it probably ultimately comes down to the individual, like, you know, for myself speaking, you know, from my own experience, I had a classical sort of computer science education training and also very much was taught the camp of the world of hard knocks. You either suffer through this pain or go change careers and pick a different degree, essentially. But I have, you know, worked at, you know, great places and with fantastic engineers that have all kinds of different backgrounds that have come from boot camps, have come, they started, you know, careers in completely different spaces and then took a boot camp, ended up at, you know, Google was a great engineer or people who, you know, started with a variety of different programming languages.

So, I mean, there's probably no right path. It really comes down to the individual and, you know, how much they get sucked into this, you know, I think wonderful world that we've been sucked into of being a builder, creating and, you know, finding passion within it. Yeah. All right, Alex, what are your thoughts?

What's your recommendations? Yeah, this was the clip I was was most excited to talk to you about because we just had completely different paths, right? Like you mentioned, you're sort of classically trained in computer science, Stanford, Google, all that sort of stuff. I was not that way. I was a liberal arts major. I went to law school.

I learned to code my last year of law school. I worked as a lawyer for a year and then just hopped over. But totally self-taught. I don't know C or C++. I don't know anything about compilers or any of that stuff i'm mostly like python and javascript i've done like a little go but like mostly like you know just the uh self-taught like web hacker type guy so i don't know i like i think it's interesting like i love that path like i always grew up like being on the internet and liking all the time. I sort of was interested in computer science going to college. And I took one computer science class and just like totally hated it.

I thought it was super boring. But then when I picked it up again, and I've been using the internet for 15 years, but now I'm like doing web development. It's like that browser where I was like going to all these different places. Now I'm going to some place that I built or I can change something locally and immediately see that in the browser and then I can deploy it and send it to my friend and he can see it. Like that was just so powerful and amazing to me. And I just think like that route of getting people hooked can be really

useful with the downside being, I have some huge gaps in my knowledge around that stuff. And I've never felt the urge to go back to see your sheep ups plus, or even like picking up rust or zig or any of this stuff so it's difficult that way like we definitely i don't know i i sort of wish um i guess let me stop there like what do you think on on this stuff so i think that i really like craig's kind of advice of do what's fun i think i that's probably some of the most helpful thing, right? Like if you're actually engaged and you find it fun,

then going back to some of the things we were talking about earlier, where you feel like, you know, I would do this for free or you easily spend like a Saturday, you know, 12 hours straight at the keyboard. Like you're not doing that because you hate what you're doing, right?

So if you can find whatever that thing is, whether it's like, you know, building a game or, you know, I don? So if you can find whatever that thing is, whether it's like building a game or I don't know, SaaS app or whatever, using whatever sort of tools and programming languages are disposable, that's great. I think even though I had that classic training,

the first couple of years of university, I did contemplate leaving because it took me a while to sort of appreciate some of the fundamental type of stuff that they were teaching me because I had already done some coding in high school and stuff like that. And I felt like, why am I learning how to program this command line algorithm? It's not very interesting or something like that. When I was used to building stuff on the web or even building GUIs and stuff that people can interact with, that just felt closer to being something

that a product that someone would use. So I felt limited in some ways. And I'm glad that I stuck with it and eventually had a lot of appreciation for it and actually went really, really deep into the theory side at one point in my life. But I think from my own experience, and I kind of commented this in the interview too, is that I think great people can kind of come from all kinds of different paths. And there's also a lot of value from like a diversity standpoint of having people who aren't just all like MIT grads,

you know, like they, because they're going to have a certain, you know, frame of reference and worldview're going to have a certain, you know, a frame of reference and worldview with how they approach problems and so forth. Like the fact that, for example, that you had a liberal arts degree and worked as a lawyer with a law school, like you might recognize or make connections on a problem that I would never, ever be able to make because I don't have that sort of background. So I think there's a tremendous amount of value of having sort of this, like when you're building like a team or a company

being open to having these like diverse backgrounds. And I think great people can come, like you have lots of examples of people who grew up and without even electricity that became, you know, fantastic people in technology and stuff. So there's not one path I think for everybody. Yep. Yep. And I think that route you took where you, like, you were sort of already hooked and you'd understand the power and ease of like building stuff. And then it's like, now you go deeper. I think that'd be a nice route for colleges to take where maybe that first or second class would be more just like web dev type stuff and getting people interested in understanding what's possible. And then people could fork off and go into compilers and operating systems and databases

if they want to, or stay more in that web dev track um i know like un university nebraska lincoln which is you know that's where i went they they had like a traditional computer science program but recently they've added like a software engineering degree which is more web dev it's like you're learning how to use git and github and things like that and like things that like you're ready to go out into the world and be productive and it's not like you just have a ton of of theory stuff but not a lot of like practical experience it's like hey you're ready to go out into the world and be productive. And it's not like you just have a ton of theory stuff, but not a lot of like practical experience. It's like, hey, you're ready to like be practical. And I know some of the people at Huddle, which is like a startup here, helped get that off the ground because they're just saying, hey, we'd love to have people that, you know, know some of those computer science basics, but also just like are ready to hit the ground running with WebDev and being a part of a software development team right away. I mean, one of the reasons people love hiring University of Waterloo graduates is because they have a very math-heavy program,

but they also, everybody's required to go through a co-op program. So by the time they graduate, they have both like really, really sort of hardcore fundamental training, but they've also spent like two years of actual like job experience. So they come out, they're like ready to rock when they come out.

So that's why like so many Waterloo grads end up in the Bay Area working for Google and the other, you know, big tech companies. Yeah. Yeah. That's a great mix of it. Yeah. Cool. Let's go to the next clip. This was a great, I love this interview too. This is Joran Dirkgrief. He's the founder of Tiger Beetle, which is a new database. And I would say it's specifically aimed at financial transactions and just safety and speed and concurrency around that sort of stuff,

which is interesting. I love how they're developing it and a lot of the stuff they're doing there. This clip is actually about licensing because we've seen a lot of the licensing wars, especially with open source and people moving to more of a closed source or business license type thing with a lot of different databases so just getting his sense on that like how do you think about the traditional apache 2 versus like you know the bsl or things like that so let's run

the clip so you know tiger beetle is apache 2 we've seen a lot of um databases or tools lately switched to BSL, the business source license or things like that. I guess, how do you think about open source and the BSL or what do you think about that? Yeah, thanks. So again, it's all about building trust, you know, build trust. So I studied accounting and my professors, I'm really thankful because the one thing they would drill into us, they would ask the question, what do auditors, you know, the big four, what do they sell? And the answer was trust. And I think in software, like so much comes down to trust. At the end of the day, it's about trust. So you can, I think this is what people miss is the business side. I think as engineers, we retreat and we say, well, we don't know much about business, so we're going to choose the license that has business in the end of the day is about trust, how do you build

trust? And I don't think you build trust by saying to your future customers, hey, you should depend on this critical dependency, but you know what? It's going to be a monopoly. It's going to be one business that can support it. I don't think you build trust like that. I don't actually think, I think we should be more as engineers, I would like us to be, I come from a business background. I think the way I look about, you know, think about open

source licenses is I always ask the question, what's good for business? Is it free? Is it permissive? Because if you can't have a lot of entrepreneurs building businesses on this, it's not a great, my book, you know, business license. So I, that's why I love, I've always loved MIT and I've loved Apache because you can build businesses on these licenses. And it's not zero sum, you know, again, it's all about trust. So, you know, your customers want to trust you and they do trust you, but they also want to trust that if something happens to your corporate entity, well, there's another one. That is better for business if you look at things as a system, as an ecosystem.

And if you want to build a great business, you can't think only of your little castle. You have to think of the fields beyond it, and you really want to get your cavalry into the field you don't want to be defensive digging moats no one wins a war like that you know you actually want to have the best cavalry in the field just go and innovate make a technical contribution builds trust this idea that we're going to lob four-year-old open source over the wall i i i don't know i'm happy you know i've got friends that you know that have you know thought they needed to do that um and that's great it's a different philosophy but i don't think it's not great for business you know i think you get far more business if if you just open source

and we've also i mean we have this legacy you know we had people the previous generation fought hard for open source and our generation i see you know people are saying it's we we say well we're engineers what do we know about business but actually i think i wish people would just say you know what let's just build trust and yeah let's just just be good um yeah yeah what about i mean that trust is such an interesting one and is there a way that you can sort of uh more permanently lock in some of that trust or things like that because like one thing that's difficult is we've seen companies that that talked about open source talked to get open source game for a while and then all this and

built up that trust it seemed like and then you know once it got to day two and and things like that now it's like hey now we're bsl going forward so like i mean yeah it's probably hard to donate your database to like the linux foundation you know like that wouldn't be um great but like is are there are there ways you can sort of like lock in that trust to where it's not just you know subject to the whims of uh of the company and whoever happens to be in leadership but you know in five 10 years as well. Yeah, I think that's also good. So we, like Tiger Beetle came out of Payment Switch, which was Apache 2.

So we had to be Apache 2 by contract. So that's nice. So we are Apache 2. I think the other thing you always, often what you find is when people bait in Switch, it's new management, and maybe they don't understand open source. They because it's always like how do people play chess are they trying to just capture you know material on the board like just capture a pawn while

actually trying to win the game and that's always my question are they thinking second order because everyone is thinking business you know bsl first I'll sleep well at night. Actually, if you look at it like Red Panda rewrote Kafka, I don't know how many years in, seven years in, they didn't even want Kafka source. They just said, well, things have changed. We're going to rewrite it, you know? So BSL wouldn't have given, not that Kafka are BSL, but it actually doesn't give you protection in the defense, you think think because by the time someone is going to compete with you, things have changed. They'll rewrite. And again, competition happens at the interface,

not at the implementation. So you can license, and this is my feeling, that you can license the implementation. People always compete on the interface. It's going to be Kafka dropping replacement. So I'm a huge fan, obviously, of Red Pandal. I think that story is interesting.

I think if you want to build trust, you also don't want to lock people in because it's kind of hard to sell if you're saying to someone, I'm going to lock you in. There's a better way to do it. You don't need to if you have trust that's actually where the money which i think for engineers resonates with all of us because we we all want to build trust and and it's just that we've we had this you know a little bit of first order thinking but actually second order thinking is where it's at yeah yeah you're

talking about selling and i know you're coming up on like production release of tiger beetle like what does selling look like for you is it support contracts is it a hosted tiger beetle is it something different what will that look like yeah so it's it's trust and time you know and the startups don't have open source is too expensive it's not free for them you know they need someone to manage it for them because they don't have time to set up managed environments. A lot of work into that. And at scale, it's trust.

So you can give someone free open source. They want to know, who do I call? So it's all about trust. You don't need to lock them in. They want to pay you to be there for them and have a relationship, a real relationship. So that's sort of how we think about it on those two. have any goosebumps you know what you can do with all these changes around testing and safety and performance but i was still figuring out the open source model but this is what i learned you know people just want trust and and save them time cool um yeah so you haven't seen that clip um i thought it was interesting what what you are was talking about about trust a few interesting things he

talked there like i think one of the more interesting ones is how he's noting that the competition is now at the interface level rather than the implementation where you've seen people move from open source to, to, to business license, but other places will say, you know what, that's a,

that's fine. We don't need to take your actual source and run it and host it that way. We can just take the API, whether that's the coffee API with red Panda and warp stream, whether that's the Mongo DB API with document DB and cosmos API, whether that's the Kafka API with Red Panda and WarpStream, whether that's the MongoDB API with DocumentDB and CosmosDB, whether that's something else where they're saying, hey, we can make the same implementation. It's really that API, which is going to be harder for you to lock down under a license anyway.

Yeah, I think a lot of the value that companies bring to something that might be like an open source product is, is, is sort of the managed service angle. Right. Like that's, that's where like a lot of the costs is like, I kind of wrote about this recently on LinkedIn in the context of privacy of like why it doesn't make sense to kind of like DIY something. And it's not necessarily about the like the original implementation costs. It's all the costs that like the actual technology, right? Why does everybody use GitHub to run Git when Git is open source and I could just run my own Git server and stuff like that? It's all the things

that you get on top of that. The user interface, ease of use, the APIs, the access control, the fact that I don't need to worry about whether the server is up or down. And if it's down and I'm paying for it, I can go and yell at somebody. That's the high value stuff for a business in a lot of ways. Yep. There's always that temptation, ramping on that build versus buy thing. I remember my first job where I was doing data warehouse type stuff and some other team wanted to use Mixpanel or something else for their sort of, you know, client data needs and stuff like that.

And I remember like feeling attacked. It's like, well, I built this. Why don't you use this thing I built? Even though it's not nearly as feature full and it's like got all these other problems, like now they're paying this entire team to like maintain it. And like looking back on that, I'm kind of ashamed because I'm like, oh, like, why did we, why did we do that stuff? Like, why don't we just go with the managed service that had all these these sort of things but um yeah it's it it it's interesting on that way but yeah i i thought jordan's like point here really interesting and especially like with um that point at the beginning about with auditors like what you're

selling is is trust on that stuff and it's not just like the end result but can they trust you um and and can other people trust you as well? I thought that was interesting. Yeah. I also liked his comment about lock-in. And one way to not get locked in is open source. I think there's other ways to also provide consumers or whoever's buying your product with not lock-in. And I think if you're actually delivering real value to a business, you don't need to lock them in. You don't need to... There's so many like, it's infinitely easy to sign up, but you want to cancel that thing. Like, you know, call somebody we're only open, you know, these like 12 minutes of the day

in a, you know, like a time zone that's like super inconvenient for you. And you're going to be on hold for 45 minutes. Like it's ridiculous. But if you have to kind of jump through those level hoops to like launch someone in, I don't feel like that's like a recipe for like a successful business because it speaks to their product, maybe not delivering that much value. Yeah, exactly. Like he was saying, like, don't be in that sort of defensive posture, the defensive crowd where you're just like, you know, trying to protect that little kingdom that you have. But like, how can you expand and keep improving and grow and, and grow and continue to give value rather than just, just locking people in. Absolutely. All right.

So next up is my conversation with Mario Zagar from InfoPip. I really love this interview. Like Mario had spent over 14 years at InfoPip. He's still there, of course, but he had so much knowledge about like every single like technical decision that they made through this timeline. And, you know, that's a long time to spend scaling any product. And, you know, basically, you know, the guy sees some shit. That's the bottom line.

You know, it seems so many different iterations of technology. Plus, he was a super nice guy. So in the clip, you'll hear him talking about some of the challenges they faced as they started to scale both their infrastructure and the teams that were working on the product. So beyond just the clearly the kind of like scale issues you have to deal with from an infrastructure standpoint, there's also challenges as you're essentially scaling teams. So at what point did having multiple teams kind of working on different things, but on the same source code and projects start to become an issue? And what were the ways that you went about trying to solve some of those issues? I imagine back in the early days

all of this was essentially a monolith that at some point you had to think about breaking up. Yeah, exactly. And this was like I think this is a totally normal approach. You just build some application and you start adding features and then you start, at least this is for us, we start getting more and more traffic, more and more customers, more and more features needed to be built into this monolith. And as we are developing this, even to some point,

it's not a problem having a lot of people working on this, but then at some point, you really start stepping on each other's toes, right? So we will touch some common code which will break, you know, totally something on the other side. Hopefully, this gets

caught by the tests. But in the end, we would really like not to, like... If I'm working on a part of the system which really doesn't have anything to do with the other part of the system, I don't want my changes to break this other part of the system. And there is also one other thing, this monolith grew bigger, and there were just more and more tests. So if I had one feature, I need to wait for all these tests that I don't really care. So if I had one feature, I need to work for all these tests that I don't really care about, which I didn't touch, to pass.

And at some point, basically at this point where we started to having two or three groups of people being really knowledgeable in this domain, this part of this monolith, we saw that maybe we should start pulling it out. It wasn't just about that. It was also about how many resources, how does this machine look like for this monolith? How much RAM or CPU do I need to have? Basically, it's a sum of everything. If I have spikes in some other system, it should be able to handle that. If I have spikes in some other part of the

system, basically both spikes should be able to survive on this machine. It started to be difficult to understand when these spikes would happen, what are these spikes, how to test this system, and so on. And it was starting to get difficult to think about the system. Like, you know, basically, I just have one small part, but actually running in a more complex environment, right? And, yeah, so basically, we had stages of this kind of how do we scale and how do we organize teams. At first, this monolith

was just kind of, okay, we need more throughput, just add more monoliths. That was it. And the second step, as more and more people got involved, we started to pull out these kind of independent parts. Billing, let's pull it out. Handling of incoming SMS messages, let's handle it totally

separate from outgoing SMS messages. And this was kind of natural thing. And we didn't start immediately dismantling everything. There were just some parts that came naturally to kind of extract and evolve on their own. And with time we got more and more such parts and it got easier to handle, to reason about them and you know to actually handle different scale requirements because incoming messages at that time were like 10 messages per second at best.

And outgoing was maybe, you know, 1,000 messages per second. So, you know, two machines were enough for incoming messages. But I needed to have like 10 machines for the outgoing. So, yeah. And also deployment cycle got easier because now I'm just deploying my part. I'm not touching everything else. I'm not touching some common code. It's like my own playground where I own the code that I write. So this was kind of the progression of how we went from single monolith application to just copying the monolith and then extracting and organizing teams around basically functionalities, standalone functionality that can evolve.

Yeah, so he in a couple of interviews I've had over the past six months or so with some people who've been in it for a long time, like scaling companies. I talked to the CTO of Sofascore a while back and the CTO of Algolia. And one of the consistent things that was kind of aligned with a lot of the stuff

that Mario's talked about as well is this practical approach to computer science. Because they're actually in the weeds doing real stuff, solving real problems. So a lot of the times, it's not about the sort of elegant whiteboard, perfect algorithm, or the perfect way of doing something that might be in a paper somewhere or something like that.'re just like you know how do i do this with this like low-end machine uh or you know for this cost structure like but my servers are burning down right now like what can we could you what band-aid can we put on this right now to like figure this stuff and it really is is interesting from like a creative process standpoint yeah yeah it's not just like you know fancy conference talks or or you know vendorware

about like how you should be ideally splitting this up in all these million microservices but like being practical about that i thought that was great when you're leading up in this clip and you're talking about being there 14 years i was kind of jealous i'm just like man that would be like just really cool though to be at a place 14 years and see that kind of incredible growth and just like all the changes and decisions and like i'm sure that's you know at the end of it there's like some warts you're like man i wish we hadn't done it that way and things like that but you've also like learned to grow with it and and you know it's a it's a reasonable outgrowth of sort of what you had uh the knowledge you had at that time the choices you had and the scaling and all that sort of thing so like i i'm just kind of jealous of his

experience there and what he's seen and and his. Yeah, I mean, you're going from, you know, I think they basically had like one, you know, server, probably with like both their database and their application running on it in a monolith to now being like, you know, like one of the largest, you know, multi-channel communication platforms in the world. Probably certain, I mean, it must be like trillions of transactions that are going through their systems, making billions of dollars in revenue every year. It's like, I mean,

that's a tremendous amount of stuff that needs to go from like that one computer to like scale that up to that level. And being there along the way, like it's such a great learning experience. It'd be amazing. Yep. Yep. And not just the technical changes you've seen,

but the organizational changes and what that looks like and, and, you know, onboarding the people to handle that. So, um, yeah, I just thought that was a, that was a, that was a really fun clip there. Yeah. I think the fun thing too, or the interesting thing was like, you know, if you, you know, earlier I, in that conversation too, I asked him if he was still having fun and, you know, he's still, he loves it. He's like, you know, even though it's been like 14 years. He lives and breathes this stuff. I'm sure he's done well with the company,

with the growth that they've had. He can retire if he wanted to, but he's just having fun. Yeah, there's still interesting challenges to solve and just at different levels, different scales. And yeah, it's cool. Okay. All right.

So the next clip is our conversation with Mare Bear, who we mentioned earlier. She's the field CISO of Lacework. And this is some of her takes on the SEC, Silver Winds, and the consequences of fining CISOs or going after them legally when systems are compromised. I've been actually tracking also ago when the SEC came out with like their refined language around requiring a four-day window for disclosing material cyber incidents that the Wall Street Journal reached out and asked me what material means. And I said, that's a good question. You know, like we're going to have to, I think the SEC like left it

open to an industry standard that we'll have to construct. And then while I said that out loud, I thought, who about we, right? And so I got together a group of 20 or 30 CISOs and we put one together. So I've been, as a result of sort of being more attuned to that issue lately, I've also been tracking those developments. And there was even a ransomware gang who made, who filed a disclosure on behalf of the victim to the SEC because the victim wasn't paying them off. So like we're seeing just like ricochets of, you know, regulatory efforts, you know, like having, I think, somewhat unintended consequences, or at least having, you know, and then recently, they also, SEC charged the SolarWinds CISO individually, as well as the company. And like, don't get me wrong, I'm sure there, it seems like there were some egregious kind of flaws in or lack of strategy there and that employees raised it repeatedly.

But like, also, I kind of like hiring the person who continuously tells me we're not good enough. And it doesn't mean that I'm going to go do everything that Chad tells me. It just means that I like having someone who points it out because even if I don't have it, like, you know, I want to know. And so I just worry that that's going to create this personal liability standard sort of building off the Joe Sullivan stuff that just like makes us as CISOs like more tuned into a fear-based decision system instead of a, you know, a rational risk-based one. And I'm curious to see how that plays out. Also, for what it's worth, I think any of us, on the one hand, I'm sure SolarWinds could have done more for their security. I don't know of a shop that is perfect. On the other hand, like a two year protracted nation state level campaign

would get into pretty much any shop I can think of, you know, or at least the vast majority, especially ones that have, you know, supply chain implications or hardware and software, as a lot of folks do, you know, anyway, just some thoughts on, on other news headlines, as you mentioned. That's, that's super interesting. I hadn't heard that. So that, that C said that they're going after personally, would that be like a fine he would pay? Would it be potential jail time? Or would it be like, Hey, you can't be an executive at a public company for four years? Like what, what sort of punishment are they looking for there? Yeah, the SEC is civil. So they, they could refer it over to DOJ or

other folks, but they can't put him in, and like, I guess they could send him to debtor's prison in some sense, you know what I mean? Like, there can be judgments. But yeah, they're seeking other damages. They're trying to bar him from ever, you know, holding an officer's position again and other other civil damages yeah wasn't the uber uber's former head of security or cso uh also um uh charged or was liable for for something there as well yeah that's joe sullivan he was convicted criminally actually um which is different uh yeah uh that's a hairy onely, he's also a friend of mine, but yeah, it was one of those where it was like, you know, there's no way that the entire board didn't know about a check that you write for a hundred thousand dollars. I mean,

come on. But, you know, he was the one who got personally indicted for it um and yeah it was i think i i just think we're at a high watermark with personal like liability whether it's civil or criminal um for cso's and that's going to change the tenor of what folks are willing to do that job and also, you know, what it takes to kind of like, you know, manage it effectively, because we've just introduced a couple, at least degrees of risk, if not categories of risk, like on some level, these risks existed, but like we hadn't seen them being implemented the way that we are now. So, yeah, I think I think it's really important. And I also think that it will. I at least hope that it will basically give folks the tools that they need internally to go to their

board and say, like, this is a business imperative, not just for me personally, but like, you know, there's there's more enforcement going on. And also the standards of the industry are MFA, are handling sensitive data with encrypted standards that are up to date or whatever you can think of that are standard security practices. And that, you know, I certainly hope that folks who, for example, are using Lacework will have that to fall back on to say, like, we're doing what industry standards dictate, which is to have good alerting to, you know, refine how we respond to those. And like, I don't, I can't imagine a regulator saying you have to be perfect but it certainly means that you're gonna have to get up and like you know jog with the rest of the class that's anything to add there no i don't think so that stresses me out all that all that sort of like that's just feels like such a hard problem to stay up on all those evolving uh

threats and that seems like a hard job i think my favorite part of that clip is your reaction at the end of this this all stresses me out true i just don't think i could be a cso it just like would not be a good fit for me it's such a hard job and i think like um one of the things i think merrick did a good job of like sort of articulating or framing there is like you know of course there's sort of egregious situations and stuff like that. There needs someone or a company needs to be held liable. But what are sort of the negative consequences or signals that you do? Like, are you going to be scaring people away, scaring the Alex's of the world away from, you know, wanting to step into that position of being a CISO?

It's like so much pressure. Yep. Or also like the sort of downstream effect or like the people underneath you where like you you sort of want people to call to call attention to these things but while you're still understanding we can't fix every single thing right now we have to like prioritize the biggest ones and and of course that leaves us open but then if there's like this paper trail of like hey someone raised this issue and it wasn't your p1 issue it was like a p2 issue but it happened to get exploited by you know some, some like she's saying, you know, any nation like these sophisticated nation states, they can get into almost anyone if they want to. And like, what does that that mean for, you know, just like reporting those issues up to your CISO and things like that, if it's going to then result in personal liability.

So I do worry about like being too overzealous there because you don't want to be combing through emails and saying like why didn't you get this when we don't realize hey you know there are a hundred other issues that are all things that were on fire and you can only do 10 of them in one year or something like that so i do worry about that that balance um that mary pointed out there yeah i mean the consequences of of a mistake or an oversight or missing something are just as you know heavy uh when it comes to security. Versus if you're on the product side, in any part of an organization, you're always balancing. There's way too many things to do than you could possibly do. So you're trying to prioritize, balance, what are the things that you're actually going to focus on? What are the P0s, P1s to do? But if you don't build a feature, usually it might be a bad decision in the long run

from a business perspective or usability perspective or whatever. But it's not necessarily like people's information got compromised or your system got compromised or something like that. So it's hard. Yeah. I don't know every other job, but I thought it was an interesting conversation. It took me...

I felt some kindred spirit with Merit. She was a lawyer. I don't ever read that job, but I thought it was an interesting conversation. It took me, like I felt some, some kindred spirit with Merritt. Like she was a lawyer. I was a lawyer. Like we got, we got some of the, she was talking about the law stuff and the disclosure with the SEC. So I thought that,

that part was fun and kind of interesting and seeing how, you know, she's working with other CISOs on, on developing that materiality standard, like what needs to be reported, like how important of a, of a bar do you need to cross before you need to start reporting that, disclosing it publicly.

Yeah, I actually think her job as a field CISO sounds a lot more fun than being the actual CISO. Being a real CISO. You'd like to tell people what they should be doing, but you're not actually on the hook when the actual states come in and hack you. Yeah, exactly. All right, cool.

Last clip I think we have of the day. This is with Somu and Akshat on the DynamoDB team. I do a lot with Dynamo. I love these guys. They've been super helpful over the years. Both been working with AWS for over a decade now. I think basically before Dynamo launched, they were there. They're both recently senior principal engineers, which is a pretty high bar at AWS and pretty impressive. So this clip was just talking about becoming that and sort of some of the stuff we talked about with Sam earlier too. Like, how do you stay on top of your field? Like, what does that look like in terms of doing research and planning and design docs versus like actual hands-on implementation stuff

and how they balance that? So let's take a look. Where do you go look for research on transaction protocols or just different things that's happening? Is that academia? Is that industry papers? Or where are you finding that stuff?

Both, right? I think there's been a lot of good work in academia starting from the 60s about transactions. It is very interesting because the inspiration we took was from one of the papers published by Phil Bernstein. And this was in the 1970s when most of us were not even born, right? So I think academia has a lot of the good research.

And then there's been a lot of good research in the industry as well now. Like there's been, industry has been doing a lot of research and we've been publishing recently as well. So industry has also been doing a lot of research. So we look back at a lot of research and we've been publishing recently as well. So industry has also been doing a lot of research. So we look back at a lot of the papers

which are published in standard computer science conferences like Usenet, Sigmar, OSDI, and then learn from what has worked in the past and what has not worked in the past and what will work for us technically, right? Like in case of transactions, the timestamp ordering, why does it work for us? We will definitely go into details.

And there's an element of that as well here as like what makes sense for us. Yeah. What does that look like at Amazon? Like, is it mostly just informal? Like, hey, did you see this new paper? Or are there like, you know, scheduled reading groups

or different things like that to make sure everyone's up on the latest stuff? What does that mean? We have scheduled reading groups because we have people of varied interests and we want to kind of learn a lot about what's happening, what's not happening. And we may not get to do that

on a day-to-day and a job basis, right? So we have people who have focused reading groups who read papers all the time and talk about like, hey, pros and cons, what did we understand, what did we not understand? What did the paper do well? What did the paper not do well? Like we had, and we talk a lot about

how to use the different things. Like for example, a big thing within Amazon is like, how do we use formal modeling tools like TLA players or P modeling, right? And we'll have scheduled groups, which kind of go dive deep into that stuff. So there are scheduled groups for everything like data structures,

algorithms, distributed systems. And I know like I've seen a lot on TLA Plus at Amazon. Is that something that, you know, both of you are doing or is that something like, hey, there's a group that's really good at that or a few people that are really good at that and they'll come help you through it.

How often are you actually using those sort of methods? So there are very few people who use TLA+, partly because it's more complex. But it's very helpful. Like, for example, with the plus scale, it's made life a lot easier for you and me to go write something. Back in the day, the TLA-plus specification was harder to write, but with the plus scale, it's very easy. When they convert it to TLA Plus specification was harder to write, but at PlusCal, it's very easy. When they converted to TLA Plus, it's easy to write. The P modeling is

something which we kind of have all developers now kind of use because it's closer to the code you would write. And it is easier to kind of prototype and P model and check a model in P and then run with that stuff. I think that's something we have asked all developers to write. TLA Plus has usually been like a niche set of developers. We use this stuff for a really very critical set of problems like Dynamo when we did

Dynamo first, we had a TLA Plus model for all of Dynamo operations to ensure that everything is correct and that's still the foundation for Dynamo in some ways. And same for transactions. We did a similar thing for transactions as well to prove the correctness of the algorithm.

And similar to that, we actually also have like a verifier, an ACID verifier which runs in production to, you know, since like whatever time has the transactions has been launched, we still run the AC asset verifier on just to you know make sure that we have not like any gaps that we have any blind spots or anything

things like that uh to to ensure protocol is correct yeah absolutely okay one more thing before we get into in terms of transactions like you're both senior principal engineers you've been at dyno for 12 years like obviously doing a lot of higher level stuff. I'm sure writing documents, writing these papers, giving talks, but Amazon is also known for being very like practical hands-on for their advanced people. Like how much during, how much time during the week do you still sit down and write code? So I think it varies, varies on like different phases of the project. Like overall, I would say like in terms of if, if I look at the like full year, um, a lot of time I think is spent in figuring out like what we are doing and how we are doing and whether it is like, you know, correct or not.

And then second phase is I think where you write like the P modeling stuff that, that someone was talking about. I think a lot of time gets spent in that and third is I think POCs where you come up with an idea you write a POC to prove that hey this actually makes sense or this actually whatever we are claiming is going to be what we would is what we are claiming is actually going to be achieved. So that's one. And then third, I would say the last part is, you know, reviewing and ensuring that operationally we are ready and ensuring that the testing that we are doing, we have like good coverage.

So I would say like writing code testing, remodeling, writing docs, it's like equal split in terms of like the time spent and if I am working on a project I would usually take something

no other developer wants to take or non-critical because I'm not blocking them in any way or fashion because I'm doing a bunch of other things

as well simultaneously so I think like Akshat said it depends on the face of the project if it's something which is

an ideation at this point in time we would write a bunch of code to kind of prove it works it doesn't work's something which is an ideation at this point in time, we would write a bunch of code to kind of prove it works, it doesn't work. Or we're doing some modeling stuff at this point in time, right? So that's how we can ensure that we are up to date and hands-on on the stuff as well.

And the other part is also code reviews, which still keep you very close connected. So that because operationally, I think if you're not connected operationally, it's very hard to debug things when you get paged at night at 2 a.m. All right. So yeah, I love that.

And just again, seeing some of the stuff of like, you know, as you move up that sort of technical bar, this isn't into management as much or executive stuff like Sam was doing. But as you move up the ranks, how does your role sort of change and what is it doing? And, you know, it as you move up the ranks, how does your role change and what does it end up

doing? And it's a lot of design work, POC type stuff, doing the P modeling, which is a tricky thing to do, but doing less of just sitting down all day and cranking out some implementation for some of that. They're still doing some of that, but again, like they're saying, being non-blocking on that. So they're not going to be holding up the project as a whole in certain ways. So trying to figure out how you can have a big impact and use your knowledge and wisdom that you've done, still stay technical, but not be blocking people, I think is interesting. Yeah. I mean, in a lot of ways, it's like the difference between being the chef at the restaurant versus

being a wine cook. The cooks are the ones that are actually hands-on, making sure that the carrot is cooked properly. But it's the chef that's thinking more at the conceptual level and orchestrating things and thinking about menus and more of that sort of stuff and digging into problems and proof of concept or thinking about the future and so forth. And whether you're in an IC role

or a really senior management role, I think a lot of your jobs are sorts of transition to some of those things. One of the things I really liked too, that they talked about was how, you know, they're still, they're always, even though they're like experts, you know, they've been working in DynamoDB and databases for a long time, been at AWS or, you know, senior principal engineers, like they're still,

you know, digging into academics and having these groups and like learning. I remember my master's thesis supervisor, you know, one of the things that he said that always stuck with me, you know, he said a lot of crazy things, but was that he said the problem that people with PhDs have is that they think that they know something. So they basically stop learning. And I love the attitude that like, you know, you're, it's, uh, that's, you're only like, it's always like, you're, you're just sort of like a beginner, you know, sort of beginner mindset. And I think that's

really important, especially in like, that's one of the great things about technology is there's always something to learn. Um, and it's moving so fast that you can't possibly know everything. And in a lot of ways, that's like an exciting place to be. Yeah. It's, it's moving so fast that you can't possibly know everything. And in a lot of ways, that's like an exciting place to be. Yeah. It's, it's interesting to like staying on top of the academia, but then also, you know,

some of the stuff they're doing inside of AWS is probably, um, ahead of some of the academia, just because they're at a scale and, and different types of problems that are hard to like really simulate in, in, in academia correctly. So just like even staying up to date on what's happening within AWS,

uh, it's kind of funny. You talk about the, you to date on what's happening within AWS, uh, it's kind of funny. You talk about the, you know, stopping learning. Once you get a PhD, there's actually this one guy that I think he's like a senior principal on Dynamo,

maybe even higher. He's worked with other databases in AWS, like very high up in Dynamo worked on it for a long time. And he's basically going to get his PhD now at Wisconsin, Madison, which like very good computer science department, all that stuff and getting a PhD. But it's also like, man, you could probably teach a lot which like very good computer science department, all that stuff and getting a PhD.

But it's also like, man, you could probably teach a lot. You could probably teach most of that, that stuff, but he's still like wanting to learn and find out his, his own stuff and how, how he can advance in a different way than he was at AWS. So,

you know, I've seen that continuing to learn that way. Yeah. It's all about that, that growth path. I think it's also, you know, I like kind of hearing from people that,

you know, they had those people, those people and folks had a very different path than me too, where they kind of like really specialized and dug deep for a long time in one particular thing where I've gone kind of like a million miles wide.

And I often think about what would my life look like if I had focused and just like went really deep in something for a long time rather than kind of going all over the place. But it's like, uh, there's different value and different skill sets. Uh, I think like being wide helps with certain things and, but being really deep.

Also, you can be a world expert and, you know, a particular thing that is allows you to do some amazing things. Yeah. Especially something that's like so niche and like, especially like a database or operating system or something like that, like you can really go deep. And then it's like you're in a community of very small number of people that can talk at that that level with you and keep learning but you're also just doing like cool stuff so yeah it's interesting to see that that specialization sort of the same with with mario you know being a company for a long time and the changes he saw there yeah awesome well

that was a lot of fun i enjoyed that i think if you're watching the video version of this too, you get a great way to see the various, you know, haircuts and lengths of hair that Alex has had over the past six months. So it's a good, good look back. And hopefully everybody out there has a good holiday and we'll see everybody in the new year with more new episodes from Soferado. Yep. Thanks, Sean. Thanks all.