The Swyx Mixtape

Today Webflow is valued at 2 billion, profitable, and is a leader of the No Code movement.Share this on Twitter Vlad's Webflow Journey: https://twitter.com/callmevlad/status/1095333269946621958Audio source: https://saastr.libsyn.com/saastr-438-webflow-ceo-vlad-magdalin-on-building-an-enduring-company-one-hard-lesson-at-a-timeswyx: [00:00:00] Vlad Magdalin started Webflow and his story , starting it several times over 16 years is when it's super inspiring and also just jaw dropping. He told a little bit of it in the SaaStr podcast, and I encourage you to listen to the whole story, but here's a clip where it really got to the wire. Vlad Magdalin: [00:00:16] I sold all the stock that I could, that I had at Intuit had basically my entire life savings, which total about 20 grand with the stock sales and poured it all into the company and got my wife on board. Got her convinced that, we were going to raise a ton of funding and a couple months, and it was off to the races.My brother Sergey moved into our tiny little condo where we had our kids' room that we cleaned out that he crashed on the floor. We somehow had this kind of perception that we had to do all of this stuff to run a startup. Like we spent half a day in a park taking professional headshots, even though we didn't have a product, we didn't have a website.We didn't have anybody who cared about like what we were building, but we just like somehow had this checkbook, like. List of things in our minds around like what real startups do. But in retrospect it was silly. And then we thought that, Hey, we have almost unlimited money.That's what it felt like at the time we have 20 grand that's in this business account. And what do you do with that first by brand new Mac books, which is exactly what we did. And here's my wife, the voice of reason saying is that the. The best idea and me rationalizing.Yeah. Like you need to have the best equipment to, to make the house, but don't worry. We're going to do this Kickstarter and we're going to raise 300 grand and everyone's going to love this product and it's going to buy into it. So, of course we pour in something like $12,000 into this Kickstarter video.We have to rent like this massive flat that looks like modern. We record this entire video around the idea of what flow, the product we're going to build. And of course it's like a plea to the Kickstarter users from other videos that we've seen that were successful. So at this point, most of our money is gone.We even had like this, the guy convinced us to do a little bit keyboard, cat impression that surgery almost. Made on the internet, but I'm glad we spared the world from that happening. And then reality started to hit at this point. We're almost out of money, but we still have all this optimism that we're going to post a Kickstarter.It's going to go bonkers. We're going to get all this money and we're going to build the product, et cetera. And on that emotional high, we decided to apply to YC thinking that, Hey, we have this great idea. We have this Kickstarter video that we're about to put up. And in the matter of two days, we got both a rejection from my saying that, they're not open to interviewing us in that round.And the Kickstarter telling us. Hey, actually, we don't support SAS software. It either has to be downloadable or it has to be something that you physically shipped to people. And of course our entire videos, like, Hey Kickstarter, Hey kicks like you can't just like ad-lib or Madlib Indiegogo in or something like that through post-production.It was essentially a completely shot project that we had to throw away. So we went into like just deep work mode, two, we moved to this place called the hacker dojo, which is. Completely free, but also pretty, you had to fight for space and had to be there like super early in the day to get a table to work on.And then. We're at the precipice of like nothing's working, we got rejected from ICU. This Kickstarter doesn't work. And right at the end of the year of 2012, my daughter gets really sick and with a life-threatening condition. And of course, when we started the company in September I had personally made the calculation of like, Hey families, healthy kids are young.If something happens, like, all we really need is catastrophic health insurance. So our health insurance was of the variety where it's like a. 10 $15,000 deductible where just the tests alone to figure out what kind of surgery she'll need came to like $12,000 or whatever. And because it's close to the end of the year before the surgery actually happens, it rolls over to January 1st and the deductible resets and all of a sudden, like we're completely out of money.I'm borrowing money on credit cards. Things are really tense at home. Thankfully, we're able to borrow enough to like pay for the surgery. And she's perfectly fine now. But things are getting so, so tense that we're just like scraping together money. We sold the family car that we had a little bit of equity and converted it to a really cheap lease and then surgery.And I figured out. Just to survive on the company front. We found this restaurant called OODA Moss, where four for $8 and 30 cents. You could order one fajita plate that came with two sort of like fajitas, but enough raw materials to make two burritos. So that was our daily sustenance. We were just like go to this place once a day have those have an $8 and 30 cents.Meals expense per day. And that was keeping us going. And the thing that really brought it home, like the one gift my wife gave me that Christmas. Cause that's how things felt at home was this placard, like this thing where this frame $20 bill that said in case of emergency break glass, and we were such a like hanging on by a thread where we started talking about.Like Sergey, my brother, and moving back to San Diego, getting his job back. I was already talking to, into a colleagues to figure out if there's a place back for me at Intuit so that we can Moonlight on the side. So big, huge lesson there. Even though we didn't have that much cash, it felt like, we had enough that it didn't give us this sense of.Frugality and sense of scarcity that we just in retrospect wasted it on these large projects, not really thinking carefully. So I would encourage every startup, like whatever cash you have, cash is King. Like it's something that gives you not just a lifeline but also the ability to To make core decisions on things that you truly need, and also read the freaking terms of service, cause that is something I still regret not doing to this day.

Emmanuel Straschnov (@estraschnov) is the founder and co-CEO of Bubble.Audio source: https://www.spreaker.com/user/10197011/how-no-code-is-enabling-entrepreneurshipswyx: [00:00:00] I've always been interested in no-code and I think it's a pretty cool to see Emmanuel Straschnov give a brief overview of the past present and future of no-code on a recent podcast with a village global. So here he is Erik Torenberg: [00:00:16] Emmanuel. I'm really intrigued because you started this so early. Give a little bit of the overview of the different phases of sort of no code acceptance.Like what were the inflection points by which it became much more accepted and much more prominent and ineffective. Emmanuel Straschnov: [00:00:33] So the very first phase for us, I mean, between 2012 and 2014 was, wait, why are you doing this? Squarespace is already here. And it's great. So that was the first phase where you had to explain.Yeah, I mean, Squarespace is great, but if you want to start Airbnb, you can do it on square Squarespace. So that's what we're working on, but that was not necessarily a messaging that was working very well because the product was not ready yet. Like no code is very much something that until you have a great product to show people are not going to believe it.Okay, then we have the community of early adopters starting in 2015. Uh, in fact, our first visible launch on product hunt, uh, in October, 2015, that went very well. I think, I mean, you know, Eric product did very well. So then I think we got on our first week, maybe like 2000 votes or something, which back then was a lot at that point in 2015.And so that was a committee of early adopters. Playing with it. Most engineers were like, this is never going to work. Uh, but you know, product people or non-technical product people in particular started being a little bit more excited about it. And then I think it's toward the end of 2018 where the community of, uh, early adopters, you know, Ben also heart of product.And like also also the macropod people started, you know, communicating more about educating the market about no-code. Turned it into the point where early 2019, when you're what Ryan Hoover, it's a lot of product and people here. Uh, Ryan Hoover wrote that post about no code where it started being much more on the map as an interesting way to build things.And then it really blew up, at least from what we could see right at the beginning of COVID where I think it was not necessarily, there's no logical relation to that, except that people had just more time to learn things. And so they had an opportunity opportunity to start spending time learning new tools.And at that point, the tools were just good enough that it became what it is today, where today I hear investors. When people pitch them, Hey, I'm building this. I have like 2 million of AR and spit on bubble. People are not going to be like, Oh, I can't invest in this. It's built on the code. People are like, okay, show me what you have.Um, and so we're not that maturity stage yet. I mean that we'll consider maturity where engineers use Bo no-code themselves, you know, to build things. And we probably need to wait another couple of years to get there, but we suddenly getting to a point where people are not surprised anymore. When you tell them you're building a no code.Erik Torenberg: [00:02:56] Yeah. You were saying that the why now is, is partially that people have have more time. Where's the, where's it going? Uh, how do you expect to evolve in the next, uh, the next few years? Emmanuel Straschnov: [00:03:06] W what I'm hoping, I think that's where it's going. It's also like a vision I have. So, you know, I hope it turns out to be true.My hope is that five years from now, we don't talk about no code anymore. And it's just, he knows the way to build things similarly to, you know, Ruby on rails. Uh, react became the new way to build things. You don't have that many people who use, you know, C plus plus to do things it's like, low-level right.And so I'm hoping that five years from now, so default stack will be a local platform, hopefully bubble. But if it's not us, I hope it's someone else because it's very much some things that world needs. And then engineers will just be part of the picture when something new is needed and they need to extend the platform with code that's where I hope it's going.

This is the narrated version of my latest blogpost.Set Explicit Help TimeoutsThis is the backstory of how a 1-2 hour task stretched into 2 weeks because I kept it to myself.A few weeks ago a customer conversation resulted in a simple documentation request. Take something undocumented, and document it. I've done this a gazillion times. I happily took it on.But when I actually looked into it, this task was different. I knew in theory how it worked, but I had never personally used this functionality before. So to document it, I had to learn it. And there was no source material, no YouTube tutorial, no Stackoverflow answer.I felt that little "uh oh" pit of despair. Our CTO had given some pointers, so I fired up my sample code, and tried them out. Didn't work. Several variations also didn't work. By then my time was up and I had to go to the next meeting.The next attempt, I realized that I didn't have an optional dependency (Elasticsearch) configured for this feature to work. Stupid me! Of course nothing I tried worked! That was on us for not having helpful errors to warn about such things, but that's a task for another day. I enabled it, and went on to try out the exact same pointers given.Still didn't work. Several variations also still didn't work. Then my time was up.If you had asked me, at the outset, how long this task would take, I would have said 1-2 hours at most. I ended up intermittently banging my head on it for 2 weeks before admitting defeat.Only when I asked for help after 2 weeks - literally typing "I need help" into Slack - did I find out that the pointers given were incorrect and we needed a deeper inspection of the source code.There were multiple failures here - my failure to go back to my CTO to pin down what exactly he meant, my lack of familiarity with something I only conceptually understood, my failure to open up source code when surface level attempts didn't work (something I preach!).But I think my biggest failure of all was letting it drag on for 2 weeks. I should have just asked for help after the first day. Or first week. Anything would've been better than 2 weeks.The real reason was this: I was new at the company and wanted to appear like I knew what I was doing, so I didn't ask for help. Keep in mind I'm someone tells people to embrace the power of ignorance. And yet, that's what I did. I was in a supportive environment and it still felt embarrassing to type the words "I need help".From now on I'll make it a point to simply call out where I'm stuck when I'm stuck.Personal Help Timeout PolicyThe trick is setting the "help timeout" — how long before you ask for help? Clearly zero timeout is too noisy, and 2 weeks is too quiet. I put it to a poll:If you have a daily standup, this is the kind of "blocker" that is ideally brought up there, limiting your help timeout to 1 day. However, in practice, there are many long-running async tasks, "important but not urgent", that don't get brought up as blockers in daily standups.It's obviously context dependent, but I'm personally fine with a 1-4 hour timeout for most things I do. Struggle is useful and you can learn a lot through it, but you should never have to struggle for more than 4 hours alone on a problem, when you have a team.Shared Help Timeout PolicyAs much as this policy might be helpful individually, I think it might be even better when set as a team. I am not in any real danger when I ask for help. But others might feel like they are.Without having a real conversation about help timeouts, it is easy to end up in a situation where implicit help timeouts vary from 1 hour to infinity, and team progress is slowed by having to overcome this barrier every time. Make it explicit, and shared, and you enable lampshading of lack of progress and normalize asking for help. Team leaders should role model this too, instead of merely saying it's ok for everyone else to ask for help.Disclosures: This is a new policy I have made for myself, but have not applied at a team level yet.

Loren Sands-Ramshaw: https://lorensr.me/The GraphQL Guide (coming soon): https://graphql.guide/TranscriptLoren Sands-Ramshaw: [00:00:00] So welcome Shawn to the GraphQL Guide interview with Shawn Swyx Wang. Is that swyx: [00:00:04] it? I pronounce that, right. It's it's my Chinese and English initials. And it's just a branding that I'm leaned into because it's unique. Yeah. I think it's great. Loren Sands-Ramshaw: [00:00:11] Yeah, definitely unique. So for those of our readers who don't yet know you, swyx: [00:00:15] Who are you, what do you do?Cool. I'm Shawn. I guess I work on developer experience at Temporal. I should be more assertive. I am head of developer experience at Temporal.io. It's a Small startup that does microservices orchestration, which is a very, very fancy name that basically runs an open-source framework spun out of Uber that we can go into more details, but really, I've done.I sort of migrated from finances, which is my first career. Then I went into Front end. So I did a JavaScript bootcamp then went into front end D started doing some speaking and writing in 2017 and got noticed by Netlify. And that's how I got into developer education, which is what we're here to talk about, I guess, and then started getting into graph QR because it was all tied into the react world.At the time. You could not ignore graph QL and Gatsby and Apollo and all the other ecosystem in, in, in place. I did. Then I then went to AWS to do the same job, essentially where they have amplify an app sync apps think is AWS has graph QL gateway as a service, which we can talk about. And I recently left to join Temporal.Loren Sands-Ramshaw: [00:01:18] Going back to when you were getting noticed you were like writing blogs and doing talks and getting out a spot Netlify how did you decide to get into developer education? swyx: [00:01:25] I didn't, there wasn't actually a decision. It was just like, let's just try this. And see what happens. So that the context was that the boot, the first job I got out of bootcamp was at Two Sigma, which is a well-known Quant hedge fund in New York.The problem was that I was in a, I didn't know it, but I got into a bad part of Two Sigma where they were severely underusing their engineers to the point where four days out of five, we were not doing anything like specifically not standing on our desk. Cause we had stand up desks. And.Explicitly given to have the okay. To do whatever we wanted, whatever because we just didn't have work. And that was, it's a, it's an enviable position, right. For for a lot of people like, Oh yeah. Paid around and do whatever you want. That's that sounds like a great job, but I don't think it's a very good job for a junior.Like someone just starting out. Right. You're not going to grow up very much. So it's like frustration. Really that I was like, okay, I'm not getting any learning at work. My, my team lead was like not doing his job. So I just started blogging and, making my own mentors, like, externally New York city has a pretty vibrant meetup scene.So I just, started doing my own talks, even though I didn't feel like an expert. And then I started doing blogging and I think the first one that really picked up for me was. When react announced that it was working on async react like concurrent mode as it is known today, but back then it was async react.So it was announced at a conference in JS conf on March in March, 2018. And I remember that night because it was a big shock to the react ecosystem and it was like a sweeping change. They touching every single part of react. So I just stayed up all night to write a walkthrough of the talk, the demo, and just really like went through everything at it.And that was the first blog post that. We've got really some notice for me and that really still bald since then. And since then I've kind of enveloped everything into this principle I've learned in public. Like when you find something interesting write it up in your own words and share it with people.And at least the people involved in working on the thing will probably read it. And if you're saving some work and if you have some unique perspective than other people will find it helpful as well. Loren Sands-Ramshaw: [00:03:26] Was there a moment where you were like, I'm going to write my own blog posts instead of reading other people's.swyx: [00:03:32] I've been doing it, unsuccessfully for like the two years prior. So there was no one single moment. It was just like focusing it on something that people actually cared about. It turns out that, you want to write things that people want to read. And that's that was a pretty big insight for me.It's not, it didn't seem like that big of an insight until you look at it. The vast quantities of developer blogs out there. And a lot of them are sort of very inward facing. They don't really answer the question of why should you care? And so I, I definitely had my mentality changed around like, okay.Like it has to be an intersection of things you're very interested in and things that other people are interested in and you can't just have one or two. Loren Sands-Ramshaw: [00:04:07] Speaking of things that people are interested to read, you have a great book on the coding careers. That's called the coding career handbook.One of your first. Customers really like the parts of it that I read. What was that like coming with the idea of the book and writing it and swyx: [00:04:20] publishing it. So there's a fun story for the reason the name is so awkward. I still don't like the name, but I just had to go with it because I didn't have anything of anything else.The reason was the original name was cracking the coding career because there was a successful technical interviews book called cracking the coding interview. And the whole point was that it w I wanted it to be apparent in the title that once you're done with the interview, once you landed the job.There's a huge gaping hole of what's next. And this th this book is targeted at the what's next. Unfortunately, Gail McDonald, the author cracking Cody career actually got in touch with me and mentioned lawyers. So I had to change the name before lunch. So, by the time, like I already had my Twitter handle up and all that, and I was just like, all right, I'll just stick with this thing.But it is an acronym. Yeah the. Point I think is that people, I think my most successful writing, like it or not has been my non-technical writing which the learning public essay has reached, hundreds of thousands of people. And I constantly get shout outs every single day about people starting to own journeys.And it's something that I really. Believe it, even though I hate, I'm not like the Tony Robbins type, I don't want to be like a lifetime life coach or anything. I just think that this worked for me and it will work for a lot more other people. So I was like, okay. I just, I should probably just write down some more advice on, on, on what I think that people need, because.I think what really crystallized it for me was when you look at career ladder. So I did a study of every p...

An untold story from Adam Grant's new book, Think Again, with special appearance by Ed Catmull and Rufus Griscom.Audio Source: https://play.acast.com/s/the-next-big-idea/gid%3A%2F%2Fart19-episode-locator%2FV0%2F8eGHqU6ud87TFzlI-OG-ar2xD8QTim65hR_4cgCWV9cTranscriptswyx: [00:00:00] I've been listening to Adam Grant, do the podcast book tour with this new book. Think again. And none of them really connected with me until this one. On the next big idea podcast. I think it resonated because he's friends with Rufus, the host. And there's a lot of good ideas in there:Challenge networksDon't let your ideas become your identityTreat arguments like a scientistAnd some thoughts on opening other people's minds by preaching, not prosecuting, having fewer pointsasking how the other person arrived at their conclusiondoing motivational interviewing. complexifying the world avoiding binary bias. So a lot of good ideas in there. I recommend listening to the whole thing. But the clip that I'm going to show you today is a, an untold story. That's not in the book about how Steve jobs was often wrong and that runs against the typical. Impression that we have a leadership that it needs to be very definitive in certain. So here it goes Rufus Griscom: [00:00:58] I think it's so nice to see examples of leaders who are more comfortable with their humility. The examples of the young Steve Jobs and the Barry Dillers of the world have always frustrated me. I feel like a lot of people have a desire to have this kind of obnoxious resolute leader mythology.Adam Grant: [00:01:17] It's interesting Rufus. I I cut a chapter from the book that just wasn't quite working. It was basically about the idea that. We think of Steve jobs as a visionary thinker. And the story we tell the myth anyway is that it was his reality distortion field, his ability to bend the world to his will, that made up a grade.And I think if you really study the history of Apple, if. Steve jobs. Hadn't surrounded himself with people who knew how to change his mind, that he might've never changed the world. He, he didn't want to make a music player. He insisted, he swore that he wouldn't make a phone. And it was, it was the team of designers and engineers around him who convinced him to do a lot of rethinking.I ended up scrapping the chapter from the book because it felt a little bit too tactical, but something really interesting happens just this was week and a half ago now. I got an email from ed Catmull out of the blue and I've admired ed, since I first became aware of Pixar, he invented computer animation, founded Pixar led it.And I got this note from him saying he was listening to my book on audible and going through the hardcover in between. And I'm just going to read this to you because I thought it was so interesting and he said, As I was listening well, am I spinner a flood of memories came back. I think I worked longer for Steve than anyone else, and I watched him change considerably, but he was always someone who understood viscerally that there's no upside in being wrong.And that was such an interesting contrast to the, the popular portrayal of Steve jobs. It doesn't mean he wasn't stubborn. But it does mean he was willing to be convinced. And ed said he said, I believe you have the essence, he was rethinking all the time. And I got my way two thirds of the time either because I convinced him or he gave up and let me do it my way.Interesting. And my question there was, I've heard from so many people that ed Catmull brought out the best in Steve jobs. Steve jobs was kinder that he was more, open-minded more thoughtful when dealing with ed than anyone else. What I'm so curious about, and I'm reaching out to ed to find out what his answer is on this.Is that just because Steve had so much respect for Ed's intellect or is it because of the strategies that ed used to open his mind or some combination of the two? Rufus Griscom: [00:03:28] Yes. Yes and no. I think this is a part of the Steve jobs story that is often ignored, which is. Again, I think we have this attraction to like the asshole, like just incredibly decisive and certain, startup founder who just drives their way forward.And the fact that Steve jobs famously had this view that people don't know what they want. He was in some sense, it was perceived to be the opposite of the scientific method. He was basically like our consumers don't know what they're going to want in five years. We have to tell them what they're going to want.But I think there was this evolution of Steve jobs to some degree in that he started off as a pretty, stubborn, difficult character. But you do get the sense reading about him that Pixar, as you say, was this incredible culture of collaboration. And I think that Steve evolved as a leader and precisely because maybe of ed Catmull and that Pixar culture.Yeah, Adam Grant: [00:04:23] I think that culture had a big impact on him from everything I've heard. It seems getting kicked out of his own company or, nudge or force that helped a little bit, failing a bunch of times maturity. But I think one of the things that, that I don't see talked about enough, Is that the whole customer thing I think is also misrepresented.The what's the apocryphal Henry Ford line, if I asked my customer what they would have wanted, they would have said a faster horse. So you can't talk to the customer. Yeah. I think that's a gross oversimplification of what Steve jobs believed from talking with dozens of people who worked with him closely for years, he was very interested in customers' problems.The things that drove them crazy, the things that frustrated them, he just didn't trust their instincts about the solution because he thought they weren't thinking far enough ahead, or they didn't have necessarily the technological expertise to figure it out. And so I think that the Apple view of the world, which is maybe a rethinking for some of us is to say, you know what?You want to do a lot of listening to find out what people's pain points are in the world, but don't always assume that they have the right solution to their own problems.

My tweet thread: https://twitter.com/swyx/status/1364107473724919809?s=20Audio source: https://fs.blog/knowledge-project/nir-eyal/ (40 mins in)Future edit: Followup episode with Cal Newport on Time Block PlanningMain Points1. Prioritize the hard stuff not the distracting stuff 2. Todo lists don't have constraints, Calendars do3. Self image of Person Who Gets Things DoneTranscriptswyx: [00:00:00] I want to share with you an idea that I've been recently very obsessed with, and it comes like many things from Cal Newport. But I'm going to use my own words. And here it goes: your Calendar as Todo List. (Why I'm getting into time block planning). We are besieged by to-do lists, open browser tabs, YouTube watch later podcast queue, Twitter, bookmarks, unread emails, notifications messages. To do lists aren't good enough. They just solve the easy problem: storage. The actual hard problems: prioritization and scheduling. Calendars or to-do lists with prioritization and scheduling built in. You have to answer questions like: what should I do first? And what's my time budget for this? Most people's calendars only track meetings with others, but why shouldn't we make appointments with ourselves? Your calendar is the only todo list, where you have a chance at a 100% completion rate.  So I heard a version of this in Shane parishes podcasts with near IUL. And I wanted to clip his version of his as well, because he writes about it in his book Indistractible.  Nir Eyal: [00:01:04] So the second step is to make time for traction. That's the second big strategy making time for traction essentially acknowledges that you can't call something a distraction unless you know what it distracted you from. And so, yeah, this is where we're actually. Yeah. So this is  a really, really important insight.Most people out there don't keep any sort of a schedule, what they keep as a to-do list. And to-do lists are horrible Shane Parrish: [00:01:26] validated right now. Oh, you're not a big to-do list guy either. No, I hit two. Do I put every, almost everything in my calendar? Nir Eyal: [00:01:32] Yes. Okay. Thank goodness. So you're already a convert and this is, this has been around for decades.Actually. This is one of the most. Well-researched time management techniques out there. This is called making an implementation intention. Literally thousands of studies have shown that you are much more likely to do what you say you're going to do when you plan a time and place to do it. It's common sense.And it's incredible how few people say, Oh, I use my to do list to get things done because that's what some guru told me. Or I read some books that's what I'm supposed to do. And they don't realize. That to-do lists are killing your productivity and they kill your productivity for a few reasons. I know I'm killing a sacred cow right now, but this is really, really important.I'm not saying don't write down things. Okay. If what you do is a brain dump of here's all the things I need to get done. That's fine. What I'm saying specifically is don't run your life with a to-do list. Don't wake up in the morning and look at your to-do list. As the first place you look, you should be looking at your calendar.Your calendar is your best todo list. And the reason todo lists are so toxic is for a few reasons. Number one, when people look at it to do list first thing in the morning, as opposed to their calendar. Do you think the first thing they do in the morning is the important thing, the hard thing, the thing they know, they really need to get done. No, of course not. They do the easy stuff, right? They do the stuff. That's not that important. The distracting stuff. It doesn't really matter if they did. That's what we tend to do. The second big problem with, to do lists is that they're not, there's no constraint to a Todo List. So what people do with to-do lists, they just add more and more and more and more and making them even less likely to finish what they say they're going to do. I've never met anybody who actually finishes everything they say they're going to do on there to do this. Unless they keep a calendar. They never finish everything. And this was me by the way, five years ago. I This is very autobiographical. And the third reason this is so toxic is that when you live like this, when day after day, week after week, month after month, year after year, you don't do what you said you're going to do. You still have unfinished tasks at the end of your day on your to-do list, you are reinforcing a self image of someone who doesn't live with personal integrity. Right? That you are reinforcing another day, went by and I didn't do what I said. I'm going to do. I lied to myself yet again, I didn't go to the gym. I didn't finish that project. I didn't make time for my kids, whatever the case might be. I didn't do what I said I was going to do. And that over time begins to become acceptable. And that's where we really lose the war. We begin to think of ourself image as someone who just can't follow through, and then it's a lost cause as opposed to.A timebox calendar with a timebox calendar. What we're doing is we're going to decide in advance, how we are going to spend our time. And the only metric of success is not. Did we check some time, some box off, right? That's not the metric of success. The only metric of success is not finishing anything. The only metric of success is did we do what we said we were going to do for as long as we said we would, without distraction. Not did I finish? Okay. This is a big. Mind shift for people. It's not about finishing the task. It's about working on the task for as long as you said you would without distraction.And it turns out that people who use that tactic actually finish more. They are actually more  productive than the to-do list people. So that's why time boxing is such an absolutely fundamentally important technique that we must use. And it's really about what I call turning our values into time. Where the first step here is to ask yourself, how, what are your values really?That's where we start, but this is very difficult for people. Cause you know, I don't know what are my values. Instead, what I tell people to do is to look at values as attributes of the person you want to become. Okay. If values are defined as attributes of the person you want to become. So what you're going to do is to ask yourself, how would the person I want to become, spend their time.And so here's where I give these three life domains. Have you, you are at the center of these three life domains. How would the person you want to become invest time in themselves?

Audio source: https://www.svelteradio.com/episodes/svelte-language-tools-with-simon-holthausen (55 mins in)My blogpost: Errors are Not Exceptionsswyx: [00:00:00] A while ago, I started learning Go and found that there was an interesting difference between how Go handles errors and exceptions compared to JavaScript. So I wrote a blog post called errors versus exceptions. And that blogpost really stuck in my mind so much so that in a recent episode of Svelte Radio i pulled it out again as my unpopular opinion so here it is.All right. Other unpopular opinions. I've got a quick one, I've been learning goal recently for my new job and I realized that. Other languages handle exceptions and errors differently than JavaScript. And I did not know that there was any other way to do this because my only prior exposure was Python and JavaScript and they treat them the same, the exact same way, but in go, or let's say in rust, you don't really throw unless you really like shit is hitting the fan and the error the program needs to end right now.Whereas in JavaScript is pretty normal to throw. Whatever area you want. And then you would just expect someone you document that someone above should catch you. You expect someone to catch you somewhere. And then the program is going to recover and continue. From an error. And so I I realized this when I, yeah.I was just like, exploring like, what is, what's the difference between errors and exceptions like that? I don't know if you guys have ever thought about it. Antony: [00:01:12] I have thought about it because in Java where I originally came from, it's two very different concepts. So it and an error, sorry.An exception is something quite normal. It's an exception to the flow of the program or the circumstance you're in. And you can even do exception, different programming, which I used to do quite a lot, where you just have. So Java has very good exception catching it. Doesn't have like JavaScript.We have to inspect what kind of code is or read some texts out of the message. It has explicit types around what you're throwing. So you can make a catch date with multiple catches and just say this type, do this, this type, do this. So an error in Jarvis thing that if you throw an error in Java, your program equates that's the end, right?And error is critical. It's your system is broken and you always never used them. Yeah. When you're programming regularly, you never really used it. You shouldn't use them, especially web apps, but for an exception, that exception is quite a normal thing. And it literally means the truest term. It's an exception to.The flow you expect to be happening. swyx: [00:02:11] Yeah. So that, that was what it took me a long while to actually get there because I've never used Java. And then th the other thing that was confusing was go actually names them the opposite way around. So which ones are errors and then areas are Antony: [00:02:22] that's complex.swyx: [00:02:24] So it really, really screwed me up. But anyway the unpopular opinion is you should not use. Throw in JavaScript, unless you can really, really avoid it. You should use, you should return an error or you should return it in some sort of error objects. I see Simon and give me a thumbs up. Yeah, definitely.That Antony: [00:02:38] is a hard wiring rework of my brain. If I was to do that, to be honest, swyx: [00:02:43] this is so normal to throw, but we should not be randomly throwing like that. It's not, it's an abusive thrill. Simon Holthausen: [00:02:48] There, there are concepts in, for example, a functional programming with this either. So you either return the normal thing or something that exception, so to speak, and then you are forced to handle that all the way up the chain.But I think that's also why it hasn't gotten so popular because if you have to explicitly handle it every time, which is generally a good thing, I think. Many people are just lazy and say, okay, I'm just going to throw a, try, catch somewhere, very up the chain and just deal with it there instead of having to pass around this either all the way up.But I think it would make for a much more robust code. More Antony: [00:03:31] predictable quotas. If you're programming, if yeah. I if you're writing a language, like you said, um, If you make it too different to everything else, that's out there, you split the camp into two types of people as those who will adopt it and change their program habits, which should be few.There are people who will just ignore it completely because it's so different to what they used to. And then there'll be the fanatics who absolutely just love it. The fact does everything differently. Again, be a small counter centers. Describe the. The Elm language quite well, possibly I've not looked at Allen swyx: [00:04:00] quite possibly either or maybe yeah.Monads yeah, and then for me, the final realization was that anytime you throw within the anything async, and the moment you have, you, you call promise and you forget to catch that error just goes out the window. It's never handled that doesn't exist and goes to the top. I actually got mad at JavaScript. I was like, wow this is the reason we have shitty programs in Java scope because we don't have really good discipline around error handling. Anyway, that's my unpopular opinion. You should, we should stop. Antony: [00:04:34] All right.

Adopting BSL to defend against AWSa "truly serverless" experience for CockroachA perpetually free relational database - what Gmail did to email4 scales for cloud: Free tier -> sustained throughput -> sole tenancy for scale -> dedicated multitenancy cluster (for the big enterprise)it turns out that developing a multitenant hosted service also helps develop for large enterprise that wants dedicated multitenant serviceAudio source: https://changelog.com/founderstalk/75Blogpost: Why we're relicensing CockroachDBShare/Comment via Tweet: https://twitter.com/swyx/status/1376470276918050818Spencer Kimball: [00:00:00] The real challenge is how do you build and deliver cockroach as a service? And that's that's where I think the future of our success is going to be made or lost. And it's a, it's a transition right now.The world's biggest companies. They want to run a relational database themselves. They want to self hosted. They want to buy software licenses. They might want to put it in private data centers or hybrid across private and public clouds. On the other hand in five years, even those companies much less, every other startup and high growth tech company, you know, they're all going to be using databases as a service in 10 years.The entire world will be, so we have to not just win where we originally set out to build cockroach DB , the way that you might run Oracle or Postgres, or my SQL if you're running yourself. But we have to also now succeed with Amazon as a direct competitor and Google and Microsoft at these big clouds that are offering databases as a service and doing quite well with those businesses.So how do we deliver Cockroach as a database as a service and effectively compete? There's a lot of really interesting answers to that question. It's by no means a foregone conclusion that a company like AWS, which is the cloud vendor incumbent really has as many advantages as you might think they have.Adam Stacoviak: [00:01:17] I didn't do that thing because unless he pays for Cockroach cloud, you say. Cockroach cloud is the simplest way to deploy a cockroach DB and is available instantly. And here's the key on AWS and Google cloud. So what's your current answer. I'm sure over time, your answer will evolve, but what's your current solution to competing with these big players?Spencer Kimball: [00:01:38] There's a number of different aspects to the successful strategy. And as you say, ours will continue to evolve. And one is you out innovate. And I think Google is probably the only of the cloud vendors that has a truly comparable technology. Amazon's better at repackaging existing open source. And, and part of that out innovating is you may have read, we made some license changes to the core of cockroach.So we adopted something called the BSL, and that's a, that's part of how you continue to out innovate. It gives you a little bit of protection. Then there's. The idea of being multi-cloud or cloud agnostic, and that includes private clouds. So the deployment flexibility is extremely important to the world's big companies that have been around for a couple of decades and have lots of existing investments in data centers and high value use cases that aren't going to be easily moved to the public cloud.And so that I think is incredibly important. You know, part of something that's worth touching on further is just how much innovation can be done in the database as a service model. And that's something that we're, we're pushing really hard on right now. Ultimately we'd like to deliver databases and with a lot less friction than they currently are delivered as a service.Right now, when you get a database as a service, there's quite a bit of cost to it. I mean, even like a sort of production ready, encrypted instance of RDS, that's sort of the minimal footprint still costs you about a hundred dollars a month. Just a lot. And you're choosing the size of nodes where those nodes are located.And there's a number of decisions that increase the friction of the process. We'd like to drive to a world where databases are, are truly serverless. And the sense that when you get a relational database, it's something that you can pay for exactly what you use. Not worry about what kind of machines, how many and so forth, or even where they're located.You just get a database and that database is truly capable of global operation. Hey, if you only use it, the East coast of the United States, great. You want to add the EU? That's extremely simple as, as simple, essentially as setting a different value in for a column and a table specifying what region the data should be stored in, or whether it should be global as an example.And further, we actually think that price is a major impediment to using something like a relational database as a service we'd like to make these things perpetually free for developers for a pretty generous tier. So think about what Gmail did in 2003, where they're effectively making a gigabyte of email free.And you know, at the time you had, it was unheard of Yahoo. Yeah. It was like five megabytes. What you got before, which it's filled up with one MP3, somebody sent you or whatever, a couple of photos. So this is a huge innovation, obviously just set a new standard for what web mail should feel like. And while Gmail is free, if you want a hundred gigabytes, you pay for it that, that extra storage space.And that's exactly how cockroach cloud is going to feel to a developer. Like we want to make perpetually free relational databases that are. The seed of an extraordinarily powerful production database, something that can scale to run, you know, retail banking for the world's largest banks that has geo replication for a high level of resilience.And that is capable of truly global operations. So that even a startup could use the free tier of cockroach cloud and you know, store data for customers in Brazil, in Brazil store data is for customers in Japan, in Japan, right. And give them a local experience. That's how big tech build services and applications.We really want to make that, so that every company in the world, even every developer, like even in a hackathon can build that way. And it's, you know, ideally easier to build that way than it is to stand something up yourself in a single availability. Adam Stacoviak: [00:05:23] That's ambitious for sure. Because one of the hardest parts is adoption and you're guaranteeing that by.Enabling that perpetually free tier that's generous so that you can tinker in a hackathon or scale your enterprise. And it's the same coverage for cloud, right? It's the same cloud. It's not, it's not like a different version of it. It's the same version Spencer Kimball: [00:05:44] regardless. Yeah. We want that to be a very continuous product experience.And I think the journey that is most evocative for me is, you know, you're starting a company which, you know, I've done. Viewfinders the canonical example I was using my head. How much easier could we have made the viewfinder experience? And that's just great, right. To have that experience, to, to make product decisions is, is pretty fundamental.But you know, the idea would be a cake. You know, Hey, you want to stand up your database, your pre-production, but you know, you have developers that are pinging it and so forth. Certainly do...

I enjoyed learning about how Cockroach is leaderless and synchronous and that makes it a lot more resilient than alternatives.Audio source: https://changelog.com/founderstalk/75Spanner paper: https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdfShare/Comment via Tweet: https://twitter.com/swyx/status/1376470276918050818Adam Stacoviak: [00:00:00] So when did you encounter the problem that you're solving today? Spencer Kimball: [00:00:04] Yeah, so databases it turns out that they have been extraordinarily central in my career. Back as early as the.com startup. I did, we go systems we built sharded, Oracle and sharded Postgres as the two sort of flavors we supported. And I got to tell you when I was at Berkeley, I wasn't very interested in databases.I mentioned graphics. That was really. Probably my key interest databases. I didn't take until my first and only year of grad school. And I just kinda took it to get some credits. I ended up being pretty interested in the course, but I didn't really think they'd be central to my career. But as soon as I hit the quote, unquote, real world databases became a central problem of big source of frustration at Wego.And then when I got to Google, that was one of the first projects that got thrown onto, which was the AdWords system, which you know, was nascent then in 2002. But it was running into problems with sharded, my SQL. And you hear this word, "sharded", but it really, you know, for listeners that aren't aware of what that implies it's, it's about taking a monolithic database like Postgres or my SQL or Oracle that really is meant for you know, a single machine.Even if that machine can be quite large and you say, well, maybe this is going to be large enough. And this is the case of ad-words when I got put on that project. So you'd say, okay, we're going to use two databases. I'll put half our customers on the first database, half on the second. And maybe at some point you start reaching capacity on those two.And so then you say, we're gonna use four, we're going to use five, or we're going to use it got up to about 32. I think when I was at that project at Google and all these different problems started to occur as you started, you know, the application complexity became quite high. Just one ridiculous practical example:the, my SQL databases had too many connections coming into them and you know, that started to cause them to cavitate. And so we solve these problems. Every morning, we had this ads war room to solve the latest set of problems related to this just basically scalability challenge with the database.And you know, I would just say that in Google AdWords by the time they replaced that sharded my sequel architecture, they'd gotten to a thousand shards. So it became, you know, thousand my SQL instances. And I've heard that Facebook has hundreds of thousands of my SQL instances. So there's kind of no end to both how scalable that architecture is.But also how much time you have to put in to truly keep scaling it. So that's, that's a scalability challenge. There's also resilience challenges.  And that is you really don't want to have a database that has a primary and a secondary, and that's been the standard way to operate databases for, you know, most of my lifetime.The problem with that solution is that the secondary. He's getting an asynchronous replication stream of data. And even if you put it in another data center, so you have a really nice failure scenario, so you can lose a data center and fail over that fail over might imply data loss because that asynchronous replication stream might not have fully made it over to the secondary when the primary dies.So you've switched over to the secondary and you realize, Oh, wait a second. I thought I had just sent that email out as an example, but it's not in my outbox. What happened? Well, the replication stream just didn't get that email into the outbox on the secondary. So it's almost like you've moved backwards in time.You've regressed to an earlier version of the state that you had in an application. And that causes huge headaches, right? I mean, if a data center was lost at Google back in 2004, let's say it would be many teams scrambling to figure out what might've gone wrong. You know, did we charge a customer twice?You know, are there. Consistency problems in the data. Cause some of the stuff got replicated and some other stuff didn't and you'd have to write cleaners and scripts that would go through things. And you just try to reason through what might've gone wrong with your use case that that's not the right way to do database replication.And certainly not. In 2020 Google started to play around with better ways to do that. As early as 2004, 2006, they built big table. Then they built in called mega store and then they built something called Spanner. And Spanner is really what inspired cockroach. And so there's scalability, there's resilience.Those are two of the biggest problems that I've faced with databases in my career that sort of gold standard these days with databases is to do what's called consistent synchronous based replication. The popular ways to do this is something called Paxos. There's something called raft and that what they do is consensus.So instead of just writing to a primary and asynchronously replicating to a secondary, you actually write to. Three data centers or three replication sites, and you are going to be committed if the majority of the replication sites respond positively or affirmatively to any particular, right? If, for example, you only write to one out of three data centers that write.Can't be committed. So you need two out of the three. And so as long as you always have two out of three, if you lose any one data center out of those three, you always are guaranteed that one of the remaining two has the exact data that you need. So as long as you only lose the minority, you have total operational sort of continuity.

The tweet thread here: https://twitter.com/AdamRackis/status/1370874399390367756This is the edited audio of our conversation; Coding Career community members can find the transcript and video on Circle!Timestamps00:00 Introductions01:35 Coding on the Fly09:09 Use Terminology13:29 Fundamentals over Frameworks17:27 TypeScript20:18 Storytelling29:30 Misc: Ownership, System Design, Teaching37:45 Working at Spotify40:28 Svelte vs React45:45 Reading Tech Books51:21 Tech Careers in Non-Tech Hubs