Podcasts about HTML

On this episode of Ruby for All, Andrew and Julie welcome Joe Masilotti, known as the ‘Turbo Native Guy,' to discuss Turbo Native. They cover what Turbo Native is, its advantages when building apps, and how it can be an effective tool for Rails developers.  Joe also gives us an update on his library, Turbo Navigator, and provides some insightful advice for those wanting to dive into Turbo Native.  He shares his experience of Rails World Conf, discusses the future of Turbo Native, and Joe shares advice for junior Rails developers interested in Turbo Native. Press download now to hear much more! [00:00:47] Joe introduces himself and discusses Turbo iOS and its benefits for Rails developers. He outlines the difficulties of building Native iOS and Android apps and explains how Turbo Native simplifies this.[00:03:12] Julie expresses interest in potentially using Turbo Native for her projects. Joe elaborates on the advantages of Turbo Native, such as avoiding the need to build and maintain separate screens for each platform. [00:04:50] Joe discusses the process of app release and approval on iOS and Android, highlighting the efficiency of Turbo Native in rolling out updates.[00:06:49] Julie asks how Turbo Native achieves its functionality and Joe describes the use of a web view that renders the mobile web content within the app. [00:08:19] Andrew talks about his expectations for app quality on his iPhone and Joe explains how Turbo iOS and Strata avoid poor native web implementations. [00:10:32] Andrew inquires about Strata, its necessity, and its impact now that it has been released. Joe clarifies that while Strata is not essential for building Turbo Native apps, it does facilitate easier communication between web content and native code, reducing boilerplate code. [00:12:28] Andrew comments on the marketing of Strata by 37signals and its positioning as a game-changer. Joe agrees it was a marketing issues and notes that Strata was branded as a third pillar of Hotwire, and he discusses a conversation he had with DHH about the positioning of Turbo, Stimulus, and Strata.  [00:14:49] Julie asks for an explanation of what Stimulus is. Andrew describes it as a lightweight JavaScript framework that integrates with HTML, providing a structured way to write JavaScript in Rails, and Joe adds that Stimulus allows for reusable JavaScript behaviors across multiple pages. [00:18:06] Andrew asks Joe about his library, Turbo Navigator. Joe explains that Turbo Navigator aims to bring Turbo iOS up to feature parity with Turbo Android, simplifying the use of Turbo Native on iOS by reducing boilerplate. Andrew mentions Joe's upcoming Turbo Native crash course. [00:20:58] Julie inquires about getting started with Turbo Native and Joe suggests watching his Rails World talks and checking out resources on his website and mentions a book he wrote coming out soon.  [00:24:21] Joe shares his positive experience at Rails World,  and he mentions the podcast booth at the conference and Andrew reminisces about RubyConf and looking forward to future events. [00:29:12] Andrew asks what Joe predicts happening in the new few months around iOS and what he's excited for. Joe anticipates a surge in interest for Turbo Native following the conference, and he's energized by increasing developer interest in Turbo Native and contemplates expanding his educational content as a result. [00:32:12] Andrew brings up a past RailsConf in Portland where he sought advice from Joe getting into iOS development and he credits Joe's suggestion to use Swift Playgrounds. Joe affirms that Swift Playgrounds is an excellent tool for leaning Swift, but for Turbo Native specifically, developers need to engage with Xcode and write Swift more directly related to app development.[00:35:03] Joe talks about Kotlin, noting its fast evolution and his plan to pick up more of the language due to demand for Android content. [00:35:35] Joe emphasizes that Turbo Native is a wrapper around a Rails website and suggests building a mobile website first before enhancing it with Turbo Native. [00:36:56] We end with Joe advising junior Rails developers that while Turbo Native is not necessary to know, it could provide a competitive advantage in the job market. Panelists:Andrew MasonJulie J.Guest:Joe MasilottiSponsors:HoneybadgerGoRailsLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. WebsiteJoe Masilotti X/TwitterJoe Masilotti WebsiteJoe Masilotti NewsletterThe reverse job board for Rails developersRails World 2023-Mobile Apps for Rails Developers with Joe Masilotti (YouTube)Turbo Native crash course-Joe MasilottiTurbo Native for iOSHotwireStradaReact NativeRemote Ruby Podcast-Episode 151: Turbo Native & Hotwire-How Polywork Supercharges DevelopmentTurbo Native DirectoryJoseph Masilotti Apps for iPhoneStimulusTurbo NavigatorSwift Playgrounds AppSwift Playgrounds KotlinXcode-SwiftUI

What does it take to make your email stand out from the crowd? Is it going straight to the Gmail Promotions folder, or worse yet, straight to Spam?!?Does email even still work? How familiar should I sound when I hit up my email list? And how do I know whether or not my emails are working? Big Jason Henderson is an email marketing expert, here today to debunk some major email marketing myths and give us all food for thought before we hit send on that next email newsletter. Beware the marketers telling you that they're crushing it when all they're doing is spending hundreds of thousands on lead generation. Know your market and keep up with it consistently, even using AI to do the research if it's an industry that you don't keep up to date with naturally. Online 'best practices' are merely ‘pooled ignorances' as we learn that copying what others tell you is working isn't always prudent. Good marketing requires executing the basics well, testing, and then staying consistent with your brand voice.Tune in and learn about split testing (images or no images, HTML versus plain text), and why ‘clarity is persuasion' as we are reminded not to be afraid to be ourselves and have a one-on-one conversation with our customer that might well elicit an actual reply! Because that's a success you can measure. Big Jason Henderson is an Email Revenue Optimization Specialist at Breakthrough Email Marketing, responsible for $850 million in email sales. Find out more at emailrevenueoptimization.com. Key Takeaways:01:24 How is email doing today? Understanding competition for the inbox03:11 How do you make your email stand out? 04:22 Debunking some of the email marketing myths07:28 Should you sound too familiar when you email? The Obama-era error09:16 What content should you include in your emails? 10:26 Advice on how to stay in your brand voice 14:28 What is a good method of testing if your email is working?24:58 Stop trying to scam Google!25:46 How to make good email copy for your clients29:40 Sending out a personal email before a promotional one 32:56 Debunking paid lead generation as true success Connect with Big Jason Henderson:Website - emailrevenueoptimization.comBe sure to subscribe to the podcast at: https://www.digitalmarketer.com/podcast/Facebook: https://www.facebook.com/digitalmarketerInstagram: https://www.instagram.com/digitalmarketer/LinkedIn: https://www.linkedin.com/company/digital-marketer/This Month's Sponsors:Conversion Fanatics - Conversion Rate Optimization AgencyGet 50% Off Monthly Blog Writing Service - BKA Content More Resources from Scalable[Free Guide & Assessment] 7 Levels of Scale

This week on we're joined by Emil Sjölander from Figma — talking about bringing Dev Mode to Figma. Dev Mode is their new workspace in Figma that's designed to bring developers and design to the same tool. The question they're trying to answer is “How do you create a home for developers in a design tool?” We go way back to Emil's startup that was acquired by Figma called Visly, how we iterated to here from 20 years ago (think PSD > HTML days), what they did to build Dev Mode, what they're doing around codegen, the popularity of design systems, and what it takes to go from zero to Dev Mode.

This week on we're joined by Emil Sjölander from Figma — talking about bringing Dev Mode to Figma. Dev Mode is their new workspace in Figma that's designed to bring developers and design to the same tool. The question they're trying to answer is “How do you create a home for developers in a design tool?” We go way back to Emil's startup that was acquired by Figma called Visly, how we iterated to here from 20 years ago (think PSD > HTML days), what they did to build Dev Mode, what they're doing around codegen, the popularity of design systems, and what it takes to go from zero to Dev Mode.

Stephanie interviews Edward Loveall, a former thoughtbotter, now software developer at Relevant Healthcare. Part of their discussion centers around Edward's blog post on the tech industry's over-reliance on GitHub. He argues for the importance of exploring alternatives to avoid dependency on a single platform and encourages readers to make informed technological choices. The conversation broadens to include how to form opinions on technology, the balance between personal preferences and team decisions, and the importance of empathy and nuance in professional interactions. Both Stephanie and Edward highlight the value of considering various perspectives and tools in software development, advocating for a flexible, open-minded approach to technology and problem-solving in the tech industry. Relevant (https://relevant.healthcare/) Let's make sure Github doesn't become the only option (https://blog.edwardloveall.com/lets-make-sure-github-doesnt-become-the-only-option) And not but (https://blog.edwardloveall.com/and-not-but) Empathy Online (https://thoughtbot.com/blog/empathy-online) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. And today, I'm joined by a very special guest, a friend of the pod and former thoughtboter, Edward Loveall. EDWARD: Hello, thanks for having me. STEPHANIE: Edward, would you share a little bit about yourself and what you're doing these days? EDWARD: Yes, I am a software developer at a company called Relevant Healthcare. We do a lot of things, but the maybe high-level summary is we take very complicated medical data and help federally-funded health centers actually understand that data and help their population's health, which is really fun and really great. STEPHANIE: Awesome. So, Edward, what is new in your world? EDWARD: Let's see, this weekend...I live in a dense city. I live in Cambridge, Massachusetts, and it's pretty dense there. And a lot of houses are very tightly packed. And delivery drivers struggle to find the numbers on the houses sometimes because A, they're old and B, there is many of them. And so, we put up house numbers because I live in, like, a three-story kind of building, but there are two different addresses in the same three stories, which is very weird. And so [laughs], delivery drivers are like, "Where is number 10 or 15?" or whatever. And so, there's two different numbers. And so, we finally put up numbers after living here for, like, four years [chuckles]. So, now, hopefully, delivery drivers in the holiday busy season will be able to find our house [laughs]. STEPHANIE: That's great. Yeah, I have kind of a similar problem where, a lot of the times, delivery folks will think that my house is the big building next door. And the worst is those at the building next door they drop off their packages inside the little, like, entryway that is locked for people who don't live there. And so, I will see my package in the window and, you know, it has my name on it. It has, like, my address on it. And [laughs] some strategies that I've used is leaving a note on the door [laughter] that is, like, "Please redeliver my package over there," and, like, I'll draw an arrow to the direction of my house. Or sometimes I've been that person to just, like, buzz random [laughter] units and just hope that they, like, let me in, and then I'll grab my package. And, you know, if I know the neighbors, I'll, like, try to apologize the next time I see them. But sometimes I'll just be like, I just need to get my package [laughs]. EDWARD: You're writing documentation for those people working out in the streets. STEPHANIE: Yeah. But I'm glad you got that sorted. EDWARD: Yeah. What about you? What's new in your world? STEPHANIE: Well, I wanted to talk a little bit about a thing that you and I have been doing lately that I have been enjoying a lot. First of all, are you familiar with the group chat trend these days? Do you know what I'm talking about? EDWARD: No. STEPHANIE: Okay. It's basically this idea that, like, everyone is just connecting with their friends via a group chat now as opposed to social media. But as a person who is not a big group chat person, I can't, like, keep up with [chuckles], like, chatting with multiple people [laughter] at once. I much prefer, like, one-on-one interaction. And, like, a month ago, I asked you if you would be willing to try having a shared note, like, a shared iOS note that we have for items that we want to discuss with each other but, you know, the next time we either talk on the phone or, I don't know, things that are, like, less urgent than a text message would communicate but, like, stuff that we don't want to forget. EDWARD: Yeah. You're, like, putting a little message in my inbox and vice versa. And yeah, we get to just kind of, whenever we want, respond to it, or think about it, or use it as a topic for a conversation later. STEPHANIE: Yeah. And I think it is kind of a playbook from, like, a one-on-one with a manager. I know that that's, like, a strategy that some folks use. But I think it works well in the context of our friendship because it's just gotten, like, richer over time. You know, maybe in the beginning, we're like, oh, like, I don't know, here are some random things that I've thought about. But now we're having, like, whole discussions in the note [laughter]. Like, we will respond to each other, like, with sub-bullets [laughs]. And then we end up not even needing to talk about it on the phone because we've already had a whole conversation about it in the note. EDWARD: Which is good because neither of us are particularly brief when talking on the phone. And [laughs] we only dedicate, like, half an hour every two weeks. It sort of helps clear the decks a little. STEPHANIE: Yeah, yeah. So, that's what I recommend. Try a shared note for [laughs] your next friendship hangout. EDWARD: Yeah, it's great. I heartily recommend it. STEPHANIE: So, one of the things that we end up talking about a lot is various things that we've been reading about tech on the web [laughs]. And we share with each other a lot of, like, blog posts, or articles, various links, and recently, something of yours kind of resurfaced. You wrote a blog post about GitHub a little while ago about how, you know, as an industry, we should make sure that GitHub doesn't become our only option. EDWARD: Yeah, this was a post I wrote, I think, back in May, or at least earlier this year, and it got a bunch of traction. And it's a somewhat, I would say, controversial article or take. GitHub just had their developer conference, and it resurfaced again. And I don't have a habit of writing particularly controversial articles, I don't think. Most of my writing history has been technical posts like tutorials. Like, I wrote a whole tutorial on how to write SQL, or I did write one about how to communicate online. But I wasn't, like, so much responding to, like, a particular person's communication or a company's communication. And this is the first big post I've written that has been a lot more very heavily opinionated, very, like, targeted at a particular thing or entity, I guess you'd say. It's been received well, I think, mostly, and I'm proud of it. But it's a different little world for me, and it's a little scary, honestly. STEPHANIE: Yeah, I hear that, having an opinion [laughs], a very strong and maybe, like, a less popular opinion, and publishing that for the world. Could you recap what the thesis of it is for our listeners? EDWARD: Yeah, and I think you did a great job of it, too. I see GitHub or really any singular piece of technology that we have in...I'll say our stack with air quotes, but it's, you know, all the tools that we use and all the things that we use. It's a risk if you only have one of those things, let's say GitHub. Like, if the only way you know how to contribute to a code repository with, you know, 17 people all committing to that repository, if the only way you know how to do that is a pull request and GitHub goes away, and you don't have pull requests anymore, how are you going to contribute to code? It's not that you couldn't figure it out, or there aren't multiple ways or even other pull request equivalents on other sites. But it is a risk to rely on one company to provide all of the things that you potentially need, or even many of the things that you potentially need, without any alternatives. So, I wanted to try to lay out A: those risks, and B: encourage people to try alternatives, to say that GitHub is not necessarily bad, although they may not actually fit what you need for various reasons, or someone else for various reasons. But you should have an alternative in your back pocket so that in case something changes, or you get locked out, or they go away, or they decide to cancel that feature, or any number of other scenarios, you have greatly diminished that risk. So, that's the main thrust of the post. STEPHANIE: Yeah, I really appreciated it because, you know, I think a lot of us probably take GitHub for granted [laughs]. And, you know, every new thing that they kind of add to the platform is like, oh, like, cool, like, I can now do this. In the post, you kind of lay out all of the different features that GitHub has rolled out over the last, you know, couple of years. And when you see it all like that, you know, like, in addition to being, like, a code repository, you now have, like, GitHub Actions for CI/CD, you know, you can deploy static pages with it. It now has, like, an in-browser editor, and then, you know, Copilot, which, like, the more things that they [laughs] roll out, the more it's becoming, like, the one-stop shop, right? That, like, do all of your work here. And I appreciated kind of, like, seeing that and being like, oh, like, is this what I want? EDWARD: Right. Yeah, exactly. Yeah. And you mentioned a bunch. There's also issues and discussions. You mentioned their in-browser editor. But so many people use VS Code, which, while it was technically made by Microsoft, it's based on Electron, which was developed at GitHub. And GitHub even, like, took away their other Electron-based editor, Atom. And then now officially recommends VS Code. And everything from deploying all the way down to, like, thinking about and prioritizing features and editing the code and all of that pretty much could happen on GitHub. I think maybe the only thing they don't currently do is host non-static sites, maybe [laughs]. That's maybe about it. And who knows? Maybe they're working on that; as far as I know, they are, so... STEPHANIE: Yeah, absolutely. You also mentioned one thing that I really liked about the content in the post was that you talked about alternatives to GitHub, even, like, alternatives to all of the different features that we mentioned. I guess I'm wondering, like, what were you hoping that a reader from your blog post, like, what they would get out of reading and, like, what they would take away from kind of sharing your opinion? EDWARD: I wanted to try to meet people where I think they might be because I think a lot of people do use GitHub, and they do take it for granted. And they do sort of see it as this thing that they must use, or they want to use even, and that's fine. That's not necessarily a bad thing. I want them to see those alternatives and have at least some idea that there is something else out there, that GitHub doesn't become just not only the default, but, like, the only thing. I mean, to just [chuckles] re-paraphrase the title of the post, I want to make sure GitHub does not become the only option, right? I want people to realize that there are other options out there and be encouraged to try them. And I have found, for me, at least, the better way to do that is not to only focus on, like, hey, don't use GitHub. Like, I hope people did not come away with only that message or even that message at all. But that it is more, hey, maybe try something else out and to encourage you to try something out. I'm going to A: share the risks with you and B: give you some actual things to try. So, I talk about the things I'm using and some other platforms and different paradigms to think about and use. So, I hope they take those. We'll see what happens in the next, you know, months or years. And I'll probably never know if it was actually just from me or from many other conversations, and thoughts, and articles, and all that kind of stuff. But that's what it takes, so... STEPHANIE: Yeah. I think the other fun thing about kind of the, like, meta-conversation we're having about having an opinion and, like, sharing it with the world is that you don't even really say like, "This is better than GitHub," or, like, kind of make a statement about, like, you shouldn't use...you don't even say, "You shouldn't use GitHub," right? The message is, like, here are some options: try it out, and, like, decide for yourself. EDWARD: Yeah, exactly. I want to empower people to do that. I don't think it would have been useful if I'd just go and say, "Hey, don't do this." It's very frustrating to me to see posts that are only negatives. And, honestly, I've probably written those posts, like, I'm not above them necessarily. But I have found that trying to help people do what you want them to do, as silly and maybe obvious as that sounds, is a more effective way to get them to do what you want them to do [laughs], as opposed to say, "Hey, stop doing the thing I don't want you to do," or attack their identity, or their job, or some other aspect of their life. Human behavior does not respond well to that generally, at least in my experience. Like, having your identity tied up in a tool or a platform is, unfortunately, pretty common in, like, a tech space. Like, oh, like, Ruby on Rails is the best piece of software or something like that. And it's like, well, you might like it, and that might be the best thing for you. And personally, I really like Ruby on Rails. I think it does a great job of what it does. But as an example, I would not use Ruby on Rails to maybe build an iOS app. I could; I think that's possible, but I don't think that's maybe the best tool for that job. And so, trying to, again, meet people where they are. STEPHANIE: I guess it kind of goes back to what you're saying. It's like, you want to help people do what they are trying to do. EDWARD: Yeah. Maybe there's a little paternalistic thinking, too, of, like, what's good for the industry, even if it feels bad for you right now. I don't love that sort of paternalistic thinking. But if it's a real risk, it seems worth at least addressing or pointing out and letting people make that decision for themselves. STEPHANIE: Yeah, absolutely. I am actually kind of curious about how do you, like, decide something for yourself? You know, like, how do you form your own opinion about technology? I think, yeah, like, a lot of people take GitHub for granted. They use it because that's just what's used, and that may or may not be a good reason for doing so. But that was a position I was in for a long time, right? You know, especially when you're newer to the industry, you're like, oh, well, this is what the company uses, or this is what, like, the industry uses. But, like, how do you start to figure out for yourself, like, do I actually like this? Does this help me meet my goals and needs? Is it doing what I want it to be doing? Do you have any thoughts about that? EDWARD: Yeah. I imagine most people listening to this have tried lots of different pieces of software and found them great, or terrible, or somewhere in between. And I don't think there's necessarily one way to do this. But I think my way has been to try lots of things, unsurprisingly, and evaluate them based on the thing that I'm trying to do. Sometimes I'll go into a new field, or a new area, or a new product, or whatever, and you just sort of use what's there, or what people have told you about, or what you heard about last, and that's fine. That's a great place to start, right? And then you start seeing maybe where it falls down, or where it is frustrating or doesn't quite meet those needs. And it takes a bit of stepping back. Again, I don't think I'm, like, going to blow anyone's mind here by this amazing secretive technique that I have for, like, discovering good software. But it's, like, sitting there and going through this iterative loop of try it, evaluate it. Be honest with, is it meeting or not meeting some particular needs? And then try something else. Or now you have a little more info to arm yourself to get to the next piece that is potentially good. As you go on in your career and you've tried many, many, many pieces of things, you start to see patterns, right? And you know, like, oh, it's not like, oh, this is how I make websites. It's like, ah, I understand that websites are made with a combination of HTML, and CSS, and JavaScript and sometimes use frameworks. And there's a database layer with an ORM. And you start to understand all the different parts. And now that you have those keywords and those pieces a little more under your control or you have more experience with them, you can use all that experience to then seek out particular pieces. I'm looking for an ORM that's built with Rust because that's the thing I need to do it for; that's the platform I need to work with. And I needed to make sure that it supports MySQL and Postgres, right? Like, it's a very targeted thing that you wouldn't know when you're starting out. But over years of experience, you understand the difference and the reasons why you might need something like that. And sometimes it's about kind of evaluating options and maybe making little test projects to play around with those things or side projects. That's why something like investment time or 20% time is so helpful and useful for that if you're the kind of person who, you know, enjoys programming on your own in your own free time like I am. And that's also a great time to do it, although it's certainly not required. And so, that's kind of how I go through and evaluate whatever tool it is that I need. For something maybe more professional or higher stakes, there's a little more evaluation upfront, right? You want to make sure you make the right choice before you spend thousands of hours using it and potentially regretting [laughs] it and having to roll it back, causing even more thousands of hours of time. So, there's obviously some scrutiny there. But, again, that also takes experience and understanding the kind of need that you have. So, yeah, it's kind of a trade-off of, like, your time, and your energy, and your experience, and your interest. You will have many different inputs from colleagues, from websites, from posts on the internet, from Twitter, or fediverse-type kind of blogging and everything in between, right? So, you take all that in, and you try a bunch of stuff, and you come out on the other side, and then you do it again. STEPHANIE: Yeah, it sounds like you really like to just experiment, and I think that's really great. And I actually have to say that I am not someone who likes to do that [laughs]. Like, it's not where I focus a lot of my time. And it's why I'm, like, glad I'm friends with you, first of all. EDWARD: [laughs] STEPHANIE: But also, I've realized I'm much more of, like, a gatherer in terms of information and opinions. Like, I like hearing about other people's experience to then, like, help inform an opinion that I might develop myself. And, you know, it's not to say that, like, I am, like, oh yeah, like, so and so said this, and so, therefore, yeah, I completely believe what they have to say. But as someone who does not particularly want to spend a ton of my time trying out things, it is really helpful to know people who do like to do that, know people who I do trust, right? And then kind of like you had mentioned, just, like, having all these different inputs. And one thing that has changed for me with more experience is, previously, a lot of, like, the basis of what I thought was the quote, unquote, "right way" to develop software was, like, asking, like, other people and, you know, their opinions becoming my own. And, you know, at some point, though, that, like, has shifted, right? Where it's like, oh, like, you know, I remember learning this from so and so, and, like, actually, I think I disagree now. Or maybe it's like, I will take one part of it and be like, yeah, I really like test-driven development in this particular way that I have figured out how I do it, but it is different still from, like, who I learned it from. And even though, like, that was kind of what I thought previously as, like, oh yeah, like, this is the way that I've adopted without room for adjustment. I think that has been a growth, I guess, that I can point to and be like, oh yeah, like, I once was in a position where maybe opinions weren't necessarily my own. But now I spend a lot more time thinking about, like, oh, like, how do I feel about this? And I think there is, like, some amount of self-reflection required, right? A lot, honestly. Like, you try things, and then you think about, like, did I like that? [laughs] One without the other doesn't necessarily fully informed opinion make. EDWARD: Yeah, absolutely. I mean, I'm really glad you brought up that, like, you've heard an opinion, or a suggestion, or an idea from somebody, and you kind of adopt it as your own for a little bit. I like to think of it as trying on ideas like you try on clothing. Or something like, let me try on this jacket. Does this fit? And maybe you like it a little bit. Or maybe you look ridiculous, and it's [laughs] not quite for you. And you don't feel like it's for you. But you have to try. You have to, like, actually do it. And that is a completely valid way to, like, kick-starting some of those opinions, getting input from friends or colleagues, or just the world around you. And, like, hearing those things and trying them is 100% valid. And I'm glad you mentioned that because if I mentioned it, I think I kind of skipped over it or went through it very quickly. So, absolutely. And you're talking about how you just take, like, one part of it maybe. That nuance, that is, I think, really critical to that whole thought, too. Everything works differently for different people. And every tool is good for other, like, different jobs. Like, it will be like saying a hammer is the best tool, and it's, like, well, it's a good tool for the right thing. But, like, I wouldn't use a hammer to, like, I don't know, level the new house numbers I put on my house, right? But I might use them to, like, hit the nail to get them in. So, it's a silly analogy, but, like, there is always nuance and different ways to apply these different tools and opinions. STEPHANIE: I like that analogy. I think it would be really funny if there was someone out there who claimed that the hammer is the best tool ever invented [laughs]. EDWARD: Oh, I'm sure. I'm sure there is, you know. I'm not going to use a drill to paint my house, though [laughs]. STEPHANIE: That's a fair point, and you don't have to [chuckles]. EDWARD: Thank you [laughs]. STEPHANIE: But, I guess, to extend this thought further, I completely and wholeheartedly agree that, like, yeah, everyone gets to decide for themselves what works for them. But also, we work in relation with others. And I'm very interested in the balance of having your own ideas and opinions about tooling, software practices, like, whatever, and then how to bring that back into, like, working on a team or, like, working with others. EDWARD: Yeah. Well, I don't know if this is exactly what you're asking, but it makes me think of: you've gone off; you've discovered a whole bunch of stuff that you think works really well for you. And then you go to work, or you go to a community that is using a very different way of working, or different tools, or different technologies. That can be a piece of friction sometimes of, like, "Oh my gosh, I love Ruby on Rails. It's the best." And someone else is like, "I really, really don't like Ruby on Rails for reasons XYZ. And we don't use it here." And that can be really tough and, honestly, sometimes even disheartening, depending on how strongly you feel about that tool and how strongly they feel about their tools. And as a young developer many years ago, I definitely had a lot more of my identity wrapped up in the tools and technologies that I used. And that has been very useful to try to separate those two. I don't claim to be perfect at it or done with that work yet. But the more I can step away and say, you know, like, this is only a tool. It is not the tool. It is not the best tool. It is a tool that can be very effective at certain things. And I've found, at least right now, the more useful thing is to get to the root of the problem you're trying to solve and make sure you agree with everybody on that premise. So, yes, you may have come from a world where fast iteration and a really fluent language interface like Ruby has and a really fast iteration cycle like Rails has, is, like, the most important need to be solved because other things have been solved. You understand what you're doing for your product, or maybe you need to iterate quickly on that product. You've figured out an audience. You're getting payroll. You're meeting all that as a business. But then you go into a business that's potentially, like, let's say, much less funded. Or they have their market fit, and now they're working on, like, extreme performance optimization, or they're working on getting, like, government compliance, or something like that. And maybe Rails is still great. This is maybe a...the analogy may fall apart here. But let's pretend it isn't for some reason. You have to agree that, hey, like, yes, we've solved problem X that Rails really helps you solve. And now we're moving on to problem Y, and Rails may not help you solve that, or whatever technology you're using may not help you solve that. And I've found it to be much more useful to stop worrying about the means, and the tools, the things in between, and worry about the ends, worry about the goal, worry about the problems you're actually trying to solve. And then you can feel really invested in trying to solve that problem together as a group, as a team, as a community. I've found that to be very helpful. And I would also like to say it is extremely difficult to let some of that stuff go. It takes a lot of work. I see you nodding along. Like, it's really, really hard. And, like I said, I'm not totally done with it either. But that's, I think, it's something I'm really working on now and something I feel really strongly about. STEPHANIE: Yeah. You mentioned the friction of, like, working in an environment where there are different opinions, which is, you know, I don't know, just, like, reality, I guess [laughs]. EDWARD: Human nature. STEPHANIE: Yeah, exactly. And one thing I was thinking about recently was, like, okay, like, so someone else maybe made a decision about using a type of technology or, like, made a decision about architecture before my time or, like, above me, or whatever, right? Like, I wasn't there, and that is okay. But also, like, how do I maintain what I believe in and hold fast to, like, my opinions based on my value system, at least, without complaining? [laughs] Because I've only seen that a little bit before, right? When it just becomes, like, venting, right? It's like, ugh, like, you know, I have seen people who are coming from maybe, like, microservices or more of a JavaScript world, and they're like, ugh, like, what is going on with Rails? Like, this sucks [laughs]. And one thing I've been trying lately is just, like, communicating when I don't agree that something's a great idea. But also, like, acknowledging that, like, yeah, but this is how it is for this team, and I'm also not in a position to change it. Or, like, I don't feel so strongly about it that I'm like, "Hey, we should totally rethink using this, like, background job [laughs] platform." But I will be like, "Hey, like, I don't like this particular thing about it. And, you know, maybe here are some things that I did to mitigate whatever thing I'm not super into," or, like, "If I had more time, this is what I would do," and just putting it out there. Sometimes, I don't get, like, engagement on it. But it's a good practice for me to be, like, this is how I can still have opinions about things, even if I'm not, at least in this particular moment, in a position to change anything. EDWARD: It sounds to me like you in, at least at the lowest level, like, you want to be acknowledged, and you want to, like, be heard. You want to be part of a process. And yes, it doesn't always go with Stephanie's initial thought, or even final thought, or Edward's final thought. But it is very helpful to know that you are heard and you are respected. And it isn't someone just, like, completely disregarding any feeling that you have. As much as we like to say programming is this very, like, I don't know, value neutral, zero emotion kind of job, like, there's tons of emotion in this job. We want to do good things for the world. We want our technology to serve the people, ultimately, at least I do, and I know you do. But we sometimes disagree on the way to do that. And so, you want to make sure you're heard. And if you can't get that at work, like, and I know you do this, but I would encourage anyone listening out there to, like, get a buddy that you can vent to or get somebody that you can express, and they will hear you. That is so valuable just as a release, in some ways, to kind of get through what you need to get through sometimes. Because it is a job, and you aren't always the person that's going to make the decisions. And, honestly, like, you do still have one decision left, which is you can go work somewhere else if it really is that bad. And, like, it's useful to know that you are staying where you are because you appreciate the trade-offs that you have: a steady paycheck, or the colleagues that you work with, or whatever. And that's fine. That's an okay trade-off. And at some point, you might want to make a different trade-off, and that's also fine. We're getting real managery and real here. But I think it's useful. Like you said, this can be a very emotional career, and it's worth acknowledging that. STEPHANIE: Yeah, you just, you know, raised a bunch of, like, very excellent points. Yeah, at the end of the day, like, you know, you can do your best to, like, propose changes or, like, introduce new tooling and, like, see how other people feel about it. But, like, yeah, if you fundamentally do not enjoy working with a critical tool that, you know, a lot of the foundation of the work that you're doing day to day is built off of, then maybe there is a place where, like, another company that's using tools that you do feel excited or, like, passionate or, like, are a better alignment with what you hope to be doing. Kind of just going back to that theme that we were talking about earlier, like, everyone gets to decide for themselves, right? Like, the tools to help them do what they want to be doing. EDWARD: And you could even, like, reframe it for yourself, where instead of it being about the tools, maybe it's about the problem. Like, you start being more invested in, like, the problem that you're solving and, okay, maybe you don't want to use microservices or whatever, but, like, maybe you can get behind that if you realign yourself. The thing you're trying to solve is not the tool. The thing you're trying to solve is the problem. And that can be a useful, like, way to mitigate that or to, like, help yourself feel okay about the thing, whatever that is. STEPHANIE: Yeah. Now, how do I have this conversation with everyone [laughter] who claims on the internet that X is the solution to all their problems or the silver bullet, [laughs] or whatever? EDWARD: Yeah, that's tough because there are some very strong opinions on the internet, as I'm sure [laughs] you've observed. I don't know if I have the answer [laughs]. Once again, nuance and indecisions. I have been currently approaching it from kind of a meta-perspective of, like, if someone says, "X is the best tool," you know, "A hammer is the best tool," right? I'm not going to go write the post that's like, "No, hammer is, in fact, not the best tool. Don't use hammers." I would maybe instead write a post that's like, "Consider what makes the best tool." I've effectively, like, raised up one level of abstraction from, we're no longer talking about is X, or Y, or Z, the best tool? We're talking about how do we even decide that? How do we even think about that? One post...I'm now just promoting my blog posts, so get ready. But one thing I wrote was this post called And Not But. And I tried to make the case that instead of saying the word but in a sentence, so, like, yeah, yeah, we might want to use hammers, but we have to use drills or whatever. I'm trying to make the case that you can use and instead. So yeah, hammers are really good, and drills are really good in these other scenarios. And trying to get that nuance in there, like, really, really putting that in there and getting people to, like, feel that better, I think, has been really helpful, for me, certainly to get through. And part of the best thing about writing a blog post is just getting your own thoughts...I mean, it's another way to vent, right? It's getting your own thoughts out somewhere. And sometimes people respond to them. You'd be surprised who just reaches out and been like, "Hey, yeah, like, I really appreciated that post. That was really great." You weren't trying to reach that person, but now you have another connection. So, a side benefit for writing blog posts [inaudible 30:17] do it, or just even getting your thoughts out via a podcast, via a video, whatever. So, I've kind of addressed that. I also wrote a post when I worked at thoughtbot called Empathy Online. And that came out of, like, frustration with seeing people being too divisive or, in my opinion, unempathetic or inconsiderate. And instead of, again, trying to just say, "Stop it, don't do that," [laughs] but trying to, like, help use what I have learned when communicating in a medium that is kind of inherently difficult to get across emotion and empathy. And so, again, it's, in some ways, unsatisfying because what you really want to do is go talk to that person that says, "Hammer is the best tool," and say, "No, stop it [laughs]," and, like, slap them on the head or whatever, politely. But I think that probably will not get you very far. And so, if your goal, really, is to change the way people think about these things, I find it way more effective to, like, zoom out and talk about that on that sort of more meta-level and that higher level. STEPHANIE: Yeah. I liked how you called it, like, a higher level of abstraction. And, honestly, the other thing I was thinking about as you were talking about the, like, divisiveness that opinions can create, there's also some aspect of it, as a reader, realizing that one person sharing their opinion does not take away your ability to have a differing opinion [laughs]. And sometimes it's tough when someone's like, "Tailwind sucks [laughs], and it is a backward step in, you know, how we write CSS," or whatever. Yes, like, sometimes that can be kind of, like, inflammatory. But if you, like, kind of are translating it or, like, reading between the lines, they're just writing about their perspective from the things that they value. And it is okay for you to value different things and, for that reason, have a different perspective on the same thing. And, I don't know, that has helped me sometimes avoid getting into that, like, headspace of wanting to argue with someone [laughs] on the internet. Or they'll be like, "This is why I am right." [laughs] Now I have to write something and share it on the internet in response [laughs]. EDWARD: There's this idea of the narcissism of minor differences. And I believe the idea is this, like, you know, you're more likely to argue with someone who, like, 90% agrees with you. But you're just, like, quibbling over that last 10%. I mean, one might call it bikeshedding. I don't know if you've heard that phrase. But the thing that I have often found, too, is that, like the GitHub post, I will get people arguing with me, like, there's the kind of stuff I expected, where it's like, "Oh, but GitHub is really good," and XYZ and that's fine. And we can have that conversation. But it's kind of surprising, and I should have expected it, that people will sometimes be like, "Hey, you didn't go far enough. You should tell people to, like, completely delete their GitHub or, like, you know, go protest in the street." And, like, maybe that's true. I'm not saying it is or isn't. But I think one thing I try to think about is, in any post, in any trying convincing argument, like, you're potentially moving someone 1 step forward, even if there's ten steps to go. But they're never going to make those ten steps if they don't make the first 1. And so, you can kind of help them get there. And someone else's post can absolutely take them from step 5 to 6 or 6 to 7 or 7 to 8. And you won't accomplish it all at once, and it's kind of a silly thing to try, and your efforts are probably lost [laughs]. Unfortunately, it's a little bit of preaching to the choir because, like, yeah, the people that are going to respond to, like, the extreme, the end are, like, the people that already get it. And the people that you're trying to convince and move along are not going to get that thing. I do want to say that I could see this being perceived as, like, a very privileged position of, like, if there's some, like, genuine atrocity happening in the world, like, it is appropriate to go to extremes many times and sometimes, and that's fine, and people are allowed to be there. I don't want to invalidate that. It's a really tricky balance. And I'm trying to say that if your goal is to vent, that's fine. And if your goal is to move people from step 3 to 4, you have to meet people at step 3. And all that's valid and okay to try to help people move in that way. But it is very tricky. And I don't want to invalidate someone who's extremely frustrated because they're at step 10, and no one else is seeing the harm that not everybody else being at step 10 is. Like, that's an incredibly reasonable place to be and an okay place to be. STEPHANIE: Yeah, yeah. The other thing you just sparked, for me, is also the, like, power of, yeah, being able to say like, "Yeah, I agree with this 50%, or 60%, or, like, 90%." And also, there's this 10% that I'm like, oh, like, I wish were different, or I wish they'd gone further, or I wish they didn't say that. Or, you know, I just straight up disagree with this step 1 sentence, but the rest of the article, you know, I really related to. And, like, teasing that apart has been very useful for me, right? Because then I'm no longer like being like, oh, was this post good or bad? Do I agree with it or don't agree with it? It's like, there's room for [laughs] all of it. EDWARD: Yeah, that's that nuance that, you know, I liked this post, and I did not agree with these two parts of it, or whatever. It's so useful. STEPHANIE: Well, thanks, Edward, so much for coming on the show and bringing that nuance to this conversation. I feel really excited about kind of what we talked about, and hopefully, it resonates with some of our listeners. EDWARD: Yeah, I hope so too. I hope I can take them from step 2 to step 3 [laughs]. STEPHANIE: On that note, shall we wrap up? EDWARD: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

An airhacks.fm conversation with Ingo Kegel (@IngoKegel) about: Java and nullability, java's java.util.Optional, typesafe HTML templates in Kotlin, statically vs. dynamic typic, what is going to replace Java?, Kotlin Multiplatform makes the difference, Kotlin IR, the Fuchsia operating system, JetBrains Fleet IDE, Nashorn and Java, Kotlin Serialization, Ktor, kotlin support in JProfiler, JProfiler coupon code: 50% off with "java2023" Ingo Kegel on twitter: @IngoKegel

David was the chief software architect and director of engineering at Stitch Fix. He's also the author of a number of books including Sustainable Web Development with Ruby on Rails and most recently Ruby on Rails Background Jobs with Sidekiq. He talks about how he made decisions while working with a medium sized team (~200 developers) at Stitch Fix. The audio quality for the first 19 minutes is not great but the correct microphones turn on right after that. Recorded at RubyConf 2023 in San Diego. A few topics covered: Ruby's origins at Stitch Fix Thoughts on Go Choosing technology and cloud services Moving off heroku Building a platform team Where Ruby and Rails fit in today The role of books and how different people learn Large Language Model's effects on technical content Related Links David's Blog Mastodon Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: Today. I want to share another conversation from RubyConf San Diego. This time it's with David Copeland. He was a chief software architect and director of engineering at stitch fix. And at the start of the conversation, you're going to hear about why he decided to write the book, sustainable web development with Ruby on rails. Unfortunately, you're also going to notice the sound quality isn't too good. We had some technical difficulties. But once you hit the 20 minute mark of the recording, the mics are going to kick in. It's going to sound way better. So I hope you stick with it. Enjoy. Ruby at Stitch Fix [00:00:35] David: Stitch Fix was a Rails shop. I had done a lot of Rails and learned a lot of things that worked and didn't work, at least in that situation. And so I started writing them down and I was like, I should probably make this more than just a document that I keep, you know, privately on my computer. Uh, so that's, you know, kind of, kind of where the genesis of that came from and just tried to, write everything down that I thought what worked, what didn't work. Uh, if you're in a situation like me. Working on a product, with a medium sized, uh, team, then I think the lessons in there will be useful, at least some of them. Um, and I've been trying to keep it up over, over the years. I think the first version came out a couple years ago, so I've been trying to make sure it's always up to date with the latest stuff and, and Rails and based on my experience and all that. [00:01:20] Jeremy: So it's interesting that you mention, medium sized team because, during the, the keynote, just a few moments ago, Matz the creator of Ruby was talking about how like, Oh, Rails is really suitable for this, this one person team, right? Small, small team. And, uh, he was like, you're not Google. So like, don't worry about, right. Can you scale to that level? Yeah. Um, and, and I wonder like when you talk about medium size or medium scale, like what are, what are we talking? [00:01:49] David: I think probably under 200 developers, I would say. because when I left Stitch Fix, it was closing in on that number of developers. And so it becomes, you know, hard to... You can kind of know who everybody is, or at least the names sound familiar of everybody. But beyond that, it's just, it's just really hard. But a lot of it was like, I don't have experience at like a thousand developer company. I have no idea what that's like, but I definitely know that Rails can work for like... 200 ish people how you can make it work basically. yeah. [00:02:21] Jeremy: The decision to use Rails, I'm assuming that was made before you joined? [00:02:26] David: Yeah, the, um, the CTO of Stitch Fix, he had come in to clean up a mess made by contractors, as often happens. They had used Django, which is like the Python version of Rails. And he, the CTO, he was more familiar with Rails. So the first two developers he hired, also familiar with Rails. There wasn't a lot to maintain with the Django app, so they were like, let's just start fresh, fresh with Rails. yeah, but it's funny because a lot of the code in that Rails app was, like, transliterated from Python. So you could, it would, it looked like the strangest Ruby code in the world because it was basically, there was no test. So they were like, let's just write the Ruby version of this Python just so we know it works. but obviously that didn't, didn't last forever, so. [00:03:07] Jeremy: So, so what's an example of a, of a tell? Where you're looking at the code and you're like, oh, this is clearly, it came from Python. [00:03:15] David: You'd see like, very, very explicit, right? Like Python, there's a lot of like single line things. very like, this sounds like a dig, but it's very simple looking code. Like, like I don't know Python, but I was able to change this Django app. And I had to, I could look at it and you can figure out immediately how it works. Cause there's. Not much to it. There's nothing fancy. So, like, this, this Ruby code, there was nothing fancy. You'd be like, well, maybe they should have memoized that, or maybe they should have taken that into another class, or you could have done this with a hash or something like that. So there was, like, none of that. It was just, like, really basic, plain code like you would see in any beginning programming language kind of thing. Which is at least nice. You can understand it. but you probably wouldn't have written it that way at first in Ruby. Thoughts on Go [00:04:05] Jeremy: Yeah, that's, that's interesting because, uh, people sometimes talk about the Go programming language and how it looks, I don't know if simple is the right word, but it's something where you look at the code and even if you don't necessarily understand Go, it's relatively straightforward. Yeah. I wonder what your thoughts are on that being a strength versus that being, like, [00:04:25] David: Yeah, so at Stitch Fix at one point we had a pro, we were moving off of Heroku and we were going to, basically build a deployment platform using ECS on AWS. And so the deployment platform was a Rails app and we built a command line tool using Ruby. And it was fine, but it was a very complicated command line tool and it was very slow. And so one of the developers was like, I'm going to rewrite it in Go. I was like, ugh, you know, because I just was not a big fan. So he rewrote it in Go. It was a bazillion times faster. And then I was like, okay, I'm going to add, I'll add a feature to it. It was extremely easy. Like, it's just like what you said. I looked at it, like, I don't know anything about Go. I know what is happening here. I can copy and paste this and change things and make it work for what I want to do. And it did work. And it was, it was pretty easy. so there's that, I mean, aesthetically it's pretty ugly and it's, I, I. I can't really defend that as a real reason to not use it, but it is kind of gross. I did do Go, I did a small project in Go after Stitch Fix, and there's this vibe in Go about like, don't create abstractions. I don't know where I got that from, but every Go I look at, I'm like we should make an abstraction for this, but it's just not the vibe. They just don't like doing that. They like it all written out. And I see the value because you can look at the code and know what it does and you don't have to chase abstractions anywhere. But. I felt like I was copying and pasting a lot of, a lot of things. Um, so I don't know. I mean, the, the team at Stitch Fix that did this like command line app in go, they're the platform team. And so their job isn't to write like web apps all day, every day. There's kind of in and out of all kinds of things. They have to try to figure out something that they don't understand quickly to debug a problem. And so I can see the value of something like go if that's your job, right? You want to go in and see what the issue is. Figure it out and be done and you're not going to necessarily develop deep expertise and whatever that thing is that you're kind of jumping into. Day to day though, I don't know. I think it would make me kind of sad. (laughs) [00:06:18] Jeremy: So, so when you say it would make you kind of sad, I mean, what, what about it? Is it, I mean, you mentioned that there's a lot of copy and pasting, so maybe there's code duplication, but are there specific things where you're like, oh, I just don't? [00:06:31] David: Yeah, so I had done a lot of Java in my past life and it felt very much like that. Where like, like the Go library for making an HTTP call for like, I want to call some web service. It's got every feature you could ever want. Everything is tweakable. You can really, you can see why it's designed that way. To dial in some performance issue or solve some really esoteric thing. It's there. But the problem is if you just want to get an JSON, it's just like huge production. And I felt like that's all I really want to do and it's just not making it very easy. And it just felt very, very cumbersome. I think that having to declare types also is a little bit of a weird mindset because, I mean, I like to make types in Ruby, I like to make classes, but I also like to just use hashes and stuff to figure it out. And then maybe I'll make a class if I figure it out, but Go, you can't. You have to have a class, you have to have a type, you have to think all that ahead of time, and it just, I'm not used to working that way, so it felt, I mean, I guess I could get used to it, but I just didn't warm up to that sort of style of working, so it just felt like I was just kind of fighting with the vibe of the language, kind of. Yeah, [00:07:40] Jeremy: so it's more of the vibe or the feel where you're writing it and you're like this seems a little too... Explicit. I feel like I have to be too verbose. It just doesn't feel natural for me to write this. [00:07:53] David: Right, it's not optimized for what in my mind is the obvious case. And maybe that's not the obvious case for the people that write Go programs. But for me, like, I just want to like get this endpoint and get the JSON back as a map. Not any easier than any other case, right? Whereas like in Ruby, right? And you can, I think if you include net HTTP, you can just type get. And it will just return whatever that is. Like, that's amazing. It's optimized for what I think is a very common use case. So it makes me feel really productive. It makes me feel pretty good. And if that doesn't work out long term, I can always use something more complicated. But I'm not required to dig into the NetHttp library just to do what in my mind is something very simple. [00:08:37] Jeremy: Yeah, I think that's something I've noticed myself in working with Ruby. I mean, you have the standard library that's very... Comprehensive and the API surface is such that, like you said there, when you're trying to do common tasks, a lot of times they have a call you make and it kind of does the thing you expected or hoped for. [00:08:56] David: Yeah, yeah. It's kind of, I mean, it's that whole optimized for programmer happiness thing. Like it does. That is the vibe of Ruby and it seems like that is still the way things are. And, you know, I, I suppose if I had a different mindset, I mean, because I work with developers who did not like using Ruby or Rails. They loved using Go or Java. And I, I guess there's probably some psychological analysis we could do about their background and history and mindset that makes that make sense. But, to me, I don't know. It's, it's nice when it's pleasant. And Ruby seems pleasant. (laughs) Choosing Technology [00:09:27] Jeremy: as a... Software Architect, or as a CTO, when, when you're choosing technology, what are some of the things you look at in terms of, you know? [00:09:38] David: Yeah, I mean, I think, like, it's a weird criteria, but I think what is something that the team is capable of executing with? Because, like, most, right, most programming languages all kind of do the same thing. Like, you can kind of get most stuff done in most common popular programming languages. So, it's probably not... It's not true that if you pick the wrong language, you can't build the app. Like, that's probably not really the case. At least for like a web app or something. so it's more like, what is the team that's here to do it? What are they comfortable and capable of doing? I worked on a project with... It was a mix of like junior engineers who knew JavaScript, and then some senior engineers from Google. And for whatever reason someone had chosen a Rails app and none of them were comfortable or really yet competent with doing Ruby on Rails and they just all hated it and like it didn't work very well. Um, and so even though, yes, Rails is a good choice for doing stuff for that team at that moment. Not a good choice. Right. So I think you have to go in and like, what, what are we going to be able to execute on so that when the business wants us to do something, we just do it. And we don't complain and we don't say, Oh, well we can't because this technology that we chose, blah, blah, blah. Like you don't ever want to say that if possible. So I think that's. That's kind of the, the top thing. I think second would be how widely supported is it? Like you don't want to be the cutting edge user that's finding all the bugs in something really. Like you want to use something that's stable. Postgres, MySQL, like those work, those are fine. The bugs have been sorted out for most common use cases. Some super fancy edge database, I don't know if I'd want to be doing, doing that you know? Choosing cloud services [00:11:15] Jeremy: How do you feel about the cloud specific services and databases? Like are you comfortable saying like, oh, I'm going to use... Google Cloud, BigQuery. Yeah. [00:11:27] David: That sort of thing. I think it would kind of fall under the same criteria that I was just, just saying like, so with AWS it's interesting 'cause when we moved from Heroku to AWS by EC2 RDS, their database thing, uh, S3, those have been around for years, probably those are gonna work, but they always introduce new things. Like we, we use RabbitMQ and AWS came out with. Some, I forget what it was, it was a queuing service similar to Rabbit. We were like, Oh, maybe we should switch to that. But it was clear that they weren't really ready to support it. So. Yeah, so we didn't, we didn't switch to that. So I, you gotta try to read the tea leaves of the provider to see are they committed to, to supporting this thing or is this there to get some enterprise client to move into the cloud. And then the idea is to move off of that transitional thing into what they do support. And it's hard to get a clear answer from them too. So it takes a little bit of research to figure out, Are they going to support this or not? Because that's what you don't want. To move everything into some very proprietary cloud system and have them sunset it and say, Oh yeah, now you've got to switch again. Uh, that kind of sucks. So, it's a little trickier. [00:12:41] Jeremy: And what kind of questions or research do you do? Is it purely a function of this thing has existed for X number of years so I feel okay? [00:12:52] David: I mean, it's kind of similar to looking at like some gem you're going to add to your project, right? So you'll, you'll look at how often does it change? Is it being updated? Uh, what is the documentation? Does it look like someone really cared about the documentation? Does the documentation look updated? Are there issues with it that are being addressed or, or not? Um, so those are good signals. I think, talking to other practitioners too can be good. Like if you've got someone who's experienced. You can say, hey, do you know anybody back channeling through, like, everybody knows somebody that works at AWS, you can probably try to get something there. at Stitch Fix, we had an enterprise support contract, and so your account manager will sometimes give you good information if you ask. Again, it's a, they're not going to come out and say, don't use this product that we have, but they might communicate that in a subtle way. So you have to triangulate from all these sources to try to. to try to figure out what, what you want to do. [00:13:50] Jeremy: Yeah, it kind of makes me wish that there was a, a site like, maybe not quite like, can I use, right? Can I use, you can see like, oh, can I use this in my browser? Is there, uh, like an AWS or a Google Cloud? Can I trust this? Can I trust this? Yeah. Is this, is this solid or not? [00:14:04] David: Right, totally. It's like, there's that, that site where you, it has all the Apple products and it says whether or not you should buy it because one may or may not be coming out or they may be getting rid of it. Like, yeah, that would... For cloud services, that would be, that would be nice. [00:14:16] Jeremy: Yeah, yeah. That's like the Mac Buyer's Guide. And then we, we need the, uh, the technology. Yeah. Maybe not buyers. Cloud Provider Buyer's Guide, yeah. I guess we are buyers. [00:14:25] David: Yeah, yeah, totally, totally. [00:14:27] Jeremy: it's interesting that you, you mentioned how you want to see that, okay, this thing is mature. I think it's going to stick around because, I, interviewed, someone who worked on, I believe it was the CloudWatch team. Okay. Daniel Vassalo, yeah. so he left AWS, uh, after I think about 10 years, and then he wrote a book called, uh, The Good Parts of AWS. Oh! And, if you read his book, most of the services he says to use are the ones that are, like, old. Yeah. He's, he's basically saying, like, S3, you know you're good. Yeah. Right? but then all these, if you look at the AWS webpage, they have who knows, I don't know how many hundreds of services. Yeah. He's, he's kind of like I worked there and I would not use, you know, all these new services. 'cause I myself, I don't trust [00:15:14] David: it yet. Right. And so, and they're working there? Yeah, they're working there. Yeah. No. One of the VPs at Stitch Fix had worked on Google Cloud and so when we were doing this transition from Heroku, he was like, we are not using Google Cloud. I was like, really? He's like AWS is far ahead of the game. Do not use Google Cloud. I was like, all right, I don't need any more info. You work there. You said don't. I'm gonna believe you. So [00:15:36] Jeremy: what, what was his did he have like a core point? [00:15:39] David: Um, so he never really had anything bad to say about Google per se. Like I think he enjoyed his time there and I think he thought highly of who he worked with and what he worked on and that sort of thing. But his, where he was coming from was like AWS was so far ahead. of Google on anything that we would use, he was like, there's, there's really no advantage to, to doing it. AWS is a known quantity, right? it's probably still the case. It's like, you know, you've heard the nobody ever got fired for using IBM or using Microsoft or whatever the thing is. Like, I think that's, that was kind of the vibe. And he was like, moving all of our infrastructure right before we're going to go public. This is a serious business. We should just use something that we know will work. And he was like, I know this will work. I'm not confident about. Google, uh, for our use case. So we shouldn't, we shouldn't risk it. So I was like, okay, I trust you because I didn't know anything about any of that stuff at the time. I knew Heroku and that was it. So, yeah. [00:16:34] Jeremy: I don't know if it's good or bad, but like you said, AWS seems to be the default choice. Yeah. And I mean, there's people who use Azure. I assume it's mostly primarily Microsoft. Yeah. And then there's Google Cloud. It's not really clear why you would pick it, unless there was a specific service or something that only they had. [00:16:55] David: Yeah, yeah. Or you're invested in Google, you know, you want to keep everything there. I mean, I don't know. I haven't really been at that level to make that kind of decision, and I would probably choose AWS for the reasons discussed, but, yeah. Moving off Heroku [00:17:10] Jeremy: And then, so at Stitch Fix, you said you moved off of Heroku [00:17:16] David: yeah. Yeah, so we were heavy into Heroku. I think that we were told that at one point we had the biggest Heroku Postgres database on their platform. Not a good place to be, right? You never want to be the biggest customer person, usually. but the problem we were facing was essentially we were going to go public. And to do that, you're under all the scrutiny. about many things, including the IT systems and the security around there. So, like, by default, a Postgres, a Heroku Postgres database is, like, on the internet. It's only secured by the password. all their services are on the internet. So, not, not ideal. they were developing their private cloud service at that time. And so that would have given us, in theory, on paper, it would have solved all of our problems. And we liked Heroku and we liked the developer experience. It was great. but... Heroku private spaces, it was still early. There's a lot of limitations that when they explained why those limitations, they were reasonable. And if we had. started from scratch on Heroku Private Spaces. It probably would have worked great, but we hadn't. So we just couldn't make it work. So we were like, okay, we're going to have to move to AWS so that everything can be basically off the internet. Like our public website needs to be on the internet and that's kind of it. So we need to, so that's basically was the, was the impetus for that. but it's too bad because I love Heroku. It was great. I mean, they were, they were a great partner. They were great. I think if Stitch Fix had started life a year later, Private Spaces. Now it's, it's, it's way different than it was then. Cause it's been, it's a mature product now, so we could have easily done that, but you know, the timing didn't work out, unfortunately. [00:18:50] Jeremy: And that was a compliance thing to, [00:18:53] David: Yeah. And compliance is weird cause they don't tell you what to do, but they give you some parameters that you need to meet. And so one of them is like how you control access. So, so going public, the compliance is around the financial data and. Ensuring that the financial data is accurate. So a lot of the systems at Stichfix were storing the financial data. We, you know, the warehouse management system was custom made. Uh, all the credit card processing was all done, like it was all in some databases that we had running in Heroku. And so those needed to be subject to stricter security than we could achieve with just a single password that we just had to remember to rotate when someone like left the team. So that was, you know, the kind of, the kind of impetus for, for all of that. [00:19:35] Jeremy: when you were using Heroku, Salesforce would have already owned it then. Did you, did you get any sense that you weren't really sure about the future of the platform while you're on it or, [00:19:45] David: At that time, no, it seemed like they were still innovating. So like, Heroku has a Redis product now. They didn't at the time we wish that they did. They told us they're working on it, but it wasn't ready. We didn't like using the third parties. Kafka was not a thing. We very much were interested in that. We would have totally used it if it was there. So they were still. Like doing bigger innovations then, then it seems like they are now. I don't know. It's weird. Like they're still there. They still make money, I assume for Salesforce. So it doesn't feel like they're going away, but they're not innovating at the pace that they were kind of back in the day. [00:20:20] Jeremy: it used to feel like when somebody's asking, I want to host a Rails app. Then you would say like, well, use Heroku because it's basically the easiest to get started. It's a known quantity and it's, it's expensive, but, it seemed for, for most people, it was worth it. and then now if I talk to people, it's like. Not what people suggest anymore. [00:20:40] David: Yeah, because there's, there's actual competitors. It's crazy to me that there was no competitors for years, and now there's like, Render and Fly. io seem to be the two popular alternatives. Um, I doubt they're any cheaper, honestly, but... You get a sense, right, that they're still innovating, still building those platforms, and they can build with, you know, all of the knowledge of what has come before them, and do things differently that might, that might help. So, I still use Heroku for personal things just because I know it, and I, you know, sometimes you don't feel like learning a new thing when you just want to get something done, but, yeah, I, I don't know if we were starting again, I don't know, maybe I'd look into those things. They, they seem like they're getting pretty mature and. Heroku's resting on its laurels, still. [00:21:26] Jeremy: I guess I never quite the mindset, right? Where you You have a platform that's doing really well and people really like it and you acquire it and then it just It seems like you would want to keep it rolling, right? (laughs) [00:21:38] David: Yeah, it's, it is wild, I mean, I guess... Why did you, what was Salesforce thinking they were going to get? Uh, who knows maybe the person at Salesforce that really wanted to purchase it isn't there. And so no one at Salesforce cares about it. I mean, there's all these weird company politics that like, who knows what's going on and you could speculate. all day. What's interesting is like, there's definitely some people in the Ruby community who work there and still are working there. And that's like a little bit of a canary for me. I'm like, all right, well, if that person's still working there, that person seems like they're on the level and, and, and, and seems pretty good. They're still working there. It, it's gotta be still a cool place to be or still doing something, something good. But, yeah, I don't know. I would, I would love to know what was going on in all the Salesforce meetings about acquiring that, how to manage it. What are their plans for it? I would love to know that stuff. [00:22:29] Jeremy: maybe you had some experience with this at Stitch Fix But I've heard with Heroku some of their support staff at least in the past they would, to some extent, actually help you troubleshoot, like, what's going on with your app. Like, if your app is, like, using a whole bunch of memory, and you're out of memory, um, they would actually kind of look into that, for you, which is interesting, because it's like, that's almost like a services thing than it is just a platform. [00:22:50] David: Yeah. I mean, they, their support, you would get, you would get escalated to like an engineer sometimes, like who worked on that stuff and they would help figure out what the problem was. Like you got the sense that everybody there really wanted the platform to be good and that they were all sort of motivated to make sure that everybody. You know, did well and used the platform. And they also were good at, like a thing that trips everybody up about Heroku is that your app restarts every day. And if you don't know anything about anything, you might think that is stupid. Why, why would I want that? That's annoying. And I definitely went through that and I complained to them a lot. And I'm like, if you only could not restart. And they very patiently and politely explained to me why that it needed to do that, they weren't going to remove that, and how to think about my app given that reality, right? Which is great because like, what company does that, right? From the engineers that are working on it, like No, nobody does that. So, yeah, no, I haven't escalated anything to support at Heroku in quite some time, so I don't know if it's still like that. I hope it is, but I'm not really, not really sure. Building a platform team [00:23:55] Jeremy: Yeah, that, uh, that reminds me a little bit of, I think it's Rackspace? There's, there's, like, another hosting provider that was pretty popular before, and they... Used to be famous for that type of support, where like your, your app's having issues and somebody's actually, uh, SSHing into your box and trying to figure out like, okay, what's going on? which if, if that's happening, then I, I can totally see where the, the price is justified. But if the support is kind of like dropping off to where it's just, they don't do that kind of thing, then yeah, I can see why it's not so much of a, yeah, [00:24:27] David: We used to think of Heroku as like they were the platform team before we had our own platform team and they, they acted like it, which was great. [00:24:35] Jeremy: Yeah, I don't have, um, experience with, render, but I, I, I did, talk to someone from there, and it does seem like they're, they're trying to fill that role, um, so, yeah, hopefully, they and, and other companies, I guess like Vercel and things like that, um, they're, they're all trying to fill that space, [00:24:55] David: Yeah, cause, cause building our own internal platform, I mean it was the right thing to do, but it's, it's a, you can't just, you have to have a team on it, it's complicated, getting all the stuff in AWS to work the way you want it to work, to have it be kind of like Heroku, like it's not trivial. if I'm a one person company, I don't want to be messing around with that particularly. I want to just have it, you know, push it up and have it go and I'm willing to pay for that. So it seems logical that there would be competitors in that space. I'm glad there are. Hopefully that'll light a fire under, under everybody. [00:25:26] Jeremy: so in your case, it sounds like you moved to having your own platform team and stuff like that, uh, partly because of the compliance thing where you're like, we need our, we need to be isolated from the internet. We're going to go to AWS. If you didn't have that requirement, do you still think like that would have been the time to, to have your own platform team and manage that all yourself? [00:25:46] David: I don't know. We, we were thinking an issue that we were running into when we got bigger, um, was that, I mean, Heroku, it, It's obviously not as flexible as AWS, but it is still very flexible. And so we had a lot of internal documentation about this is how you use Heroku to do X, Y, and Z. This is how you set up a Stitch Fix app for Heroku. Like there was just the way that we wanted it to be used to sort of. Just make it all manageable. And so we were considering having a team spun up to sort of add some tooling around that to sort of make that a little bit easier for everybody. So I think there may have been something around there. I don't know if it would have been called a platform team. Maybe we call, we thought about calling it like developer happiness or because you got developer experience or something. We, we probably would have had something there, but. I do wonder how easy it would have been to fund that team with developers if we hadn't had these sort of business constraints around there. yeah, um, I don't know. You get to a certain size, you need some kind of manageability and consistency no matter what you're using underneath. So you've got to have, somebody has to own it to make sure that it's, that it's happening. [00:26:50] Jeremy: So even at your, your architect level, you still think it would have been a challenge to, to. Come to the executive team and go like, I need funding to build this team. [00:27:00] David: You know, certainly it's a challenge because everybody, you know, right? Nobody wants to put developers in anything, right? There are, there are a commodity and I mean, that is kind of the job of like, you know, the staff engineer or the architect at a company is you don't have, you don't have the power to put anybody on anything you, you have the power to Schedule a meeting with a VP or the CTO and they will listen to you. And that's basically, you've got to use that power to convince them of what you want done. And they're all reasonable people, but they're balancing 20 other priorities. So it would, I would have had to, it would have been a harder case to make that, Hey, I want to take three engineers. And have them write tooling to make Heroku easier to use. What? Heroku is not easy to use. Why aren't, you know, so you really, I would, it would be a little bit more of a stretch to walk them through it. I think a case could be made, but, definitely would take some more, more convincing than, than what was needed in our case. [00:27:53] Jeremy: Yeah. And I guess if you're able to contrast that with, you were saying, Oh, I need three people to help me make Heroku easier. Your actual platform team on AWS, I imagine was much larger, right? [00:28:03] David: Initially it was, there was, it was three people did the initial move over. And so by the time we went public, we'd been on this new system for, I don't know, six to nine months. I can't remember exactly. And so at that time the platform team was four or five people, and I, I mean, so percentage wise, right, the engineering team was maybe almost 200, 150, 200. So percentage wise, maybe a little small, I don't know. but it kind of gets back to the power of like the rails and the one person framework. Like everything we did was very much the same And so the Rails app that managed the deployment was very simple. The, the command line app, even the Go one with all of its verbosity was very, very simple. so it was pretty easy for that small team to manage. but, Yeah, so it was sort of like for redundancy, we probably needed more than three or four people because you know, somebody goes out sick or takes a vacation. That's a significant part of the team. But in terms of like just managing the complexity and building it and maintaining it, like it worked pretty well with, you know, four or five people. Where Rails fits in vs other technology [00:29:09] Jeremy: So during the Keynote today, they were talking about how companies like GitHub and Shopify and so on, they're, they're using Rails and they're, they're successful and they're fairly large. but I think the thing that was sort of unsaid was the fact that. These companies, while they use Rails, they use a lot of other, technology as well. And, and, and kind of increasing amounts as well. So, I wonder from your perspective, either from your experience at StitchFix or maybe going forward, what is the role that, that Ruby and Rails plays? Like, where does it make sense for that to be used versus like, Okay, we need to go and build something in Java or, you know, or Go, that sort of thing? [00:29:51] David: right. I mean, I think for like your standard database backed web app, it's obviously great. especially if your sort of mindset bought into server side rendering, it's going to be great at that. so like internal tools, like the customer service dashboard or... You know, something for like somebody who works at a company to use. Like, it's really great because you can go super fast. You're not going to be under a lot of performance constraints. So you kind of don't even have to think about it. Don't even have to solve it. You can, but you don't have to, where it wouldn't work, I guess, you know, if you have really strict performance. Requirements, you know, like a, a Go version of some API server is going to use like percentages of what, of what Rails would use. If that's meaningful, if what you're spending on memory or compute is, is meaningful, then, then yeah. That, that becomes worthy of consideration. I guess if you're, you know, if you're making a mobile app, you probably need to make a mobile app and use those platforms. I mean, I guess you can wrap a Rails app sort of, but you're still making, you still need to make a mobile app, that does something. yeah. And then, you know, interestingly, the data science part of Stitch Fix was not part of the engineering team. They were kind of a separate org. I think Ruby and Rails was probably the only thing they didn't use over there. Like all the ML stuff, everything is either Java or Scala or Python. They use all that stuff. And so, yeah, if you want to do AI and ML with Ruby, you, it's, it's hard cause there's just not a lot there. You really probably should use Python. It'll make your life easier. so yeah, those would be some of the considerations, I guess. [00:31:31] Jeremy: Yeah, so I guess in the case of, ML, Python, certainly, just because of the, the ecosystem, for maybe making a command line application, maybe Go, um, Go or Rust, perhaps, [00:31:44] David: Right. Cause you just get a single binary. Like the problem, I mean, I wrote this book on Ruby command line apps and the biggest problem is like, how do I get the Ruby VM to be anywhere so that it can then run my like awesome scripts? Like that's kind of a huge pain. (laughs) So [00:31:59] Jeremy: and then you said, like, if it's Very performance sensitive, which I am kind of curious in, in your experience with the companies you've worked at, when you're taking on a project like that, do you know up front where you're like, Oh, the CPU and memory usage is going to be a problem, or is it's like you build it and you're like, Oh, this isn't working. So now I know. [00:32:18] David: yeah, I mean, I, I don't have a ton of great experience there at Stitch Fix. The biggest expense the company had was the inventory. So like the, the cost of AWS was just de minimis compared to all that. So nobody ever came and said, Hey, you've got to like really save costs on, on that stuff. Cause it just didn't really matter. at the, the mental health startup I was at, it was too early. But again, the labor costs were just far, far exceeded the amount of money I was spending on, on, um, you know, compute and infrastructure and stuff like that. So, Not knowing anything, I would probably just sort of wait and see if it's a problem. But I suppose you always take into account, like, what am I actually building? And like, what does this business have to scale to, to make it worthwhile? And therefore you can kind of do a little bit of planning ahead there. But, I dunno, I think it would kind of have to depend. [00:33:07] Jeremy: There's a sort of, I guess you could call it a meme, where people say like, Oh, it's, it's not, it's not Rails that's slow, it's the, the database that's slow. And, uh, I wonder, is that, is that accurate in your experience, or, [00:33:20] David: I mean, most of the stuff that we had that was slow was the database, because like, it's really easy to write a crappy query in Rails if you're not, if you're not careful, and then it's really easy to design a database that doesn't have any indexes if you're not careful. Like, you, you kind of need to know that, But of course, those are easy to fix too, because you just add the index, especially if it's before the database gets too big where we're adding indexes is problematic. But, I think those are just easy performance mistakes to make. Uh, especially with Rails because you're not, I mean, a lot of the Rails developers at Citrix did not know SQL at all. I mean, they had to learn it eventually, but they didn't know it at all. So they're not even knowing that what they're writing could possibly be problematic. It's just, you're writing it the Rails way and it just kind of works. And at a small scale, it does. And it doesn't matter until, until one day it does. [00:34:06] Jeremy: And then in, in the context of, let's say, using ActiveRecord and instantiating the objects, or, uh, the time it takes to render templates, that kinds of things, to, at least in your experience, that wasn't such of an issue. [00:34:20] David: No, and it was always, I mean, whenever we looked at why something was slow, it was always the database and like, you know, you're iterating over some active records and then, and then, you know, you're going into there and you're just following this object graph. I've got a lot of the, a lot of the software at Stitch Fix was like internal stuff and it was visualizing complicated data out of the database. And so if you didn't think about it, you would just start dereferencing and following those relationships and you have this just massive view and like the HTML is fine. It's just that to render this div, you're. Digging into some active record super deep. and so, you know, that was usually the, the, the problems that we would see and they're usually easy enough to fix by making an index or. Sometimes you do some caching or something like that. and that solved most of the, most of the issues [00:35:09] Jeremy: The different ways people learn [00:35:09] Jeremy: so you're also the author of the book, Sustainable Web Development with Ruby on Rails. And when you talk to people about like how they learn things, a lot of them are going on YouTube, they're going on, uh, you know, looking for blogs and things like that. And so as an author, what do you think the role is of, of books now? Yeah, [00:35:29] David: I have thought about this a lot, because I, when I first got started, I'm pretty old, so books were all you had, really. Um, so they seem very normal and natural to me, but... does someone want to sit down and read a 400 page technical book? I don't know. so Dave Thomas who runs Pragmatic Bookshelf, he was on a podcast and was asked the same question and basically his answer, which is my answer, is like a long form book is where you can really lay out your thinking, really clarify what you mean, really take the time to develop sometimes nuanced, examples or nuanced takes on something that are Pretty hard to do in a short form video or in a blog post. Because the expectation is, you know, someone sends you an hour long YouTube video, you're probably not going to watch that. Two minute YouTube video is sure, but you can't, you can't get into so much, kind of nuanced detail. And so I thought that was, was right. And that was kind of my motivation for writing. I've got some thoughts. They're too detailed. It's, it's too much set up for a blog post. There's too much of a nuanced element to like, really get across. So I need to like, write more. And that means that someone's going to have to read more to kind of get to it. But hopefully it'll be, it'll be valuable. one of the sessions that we're doing later today is Ruby content creators, where it's going to be me and Noel Rappin and Dave Thomas representing the old school dudes that write books and probably a bunch of other people that do, you know, podcasts videos. It'd be interesting to see, I really want to know how do people learn stuff? Because if no one reads books to learn things, then there's not a lot of point in doing it. But if there is value, then, you know. It should be good and should be accessible to people. So, that's why I do it. But I definitely recognize maybe I'm too old and, uh, I'm not hip with the kids or, or whatever, whatever the case is. I don't know. [00:37:20] Jeremy: it's tricky because, I think it depends on where you are in the process of learning that thing. Because, let's say, you know a fair amount about the technology already. And you look at a book, in a lot of cases it's, it's sort of like taking you from nothing to something. And so you're like, well, maybe half of this isn't relevant to me, but then if I don't read it, then I'm probably missing a lot still. And so you're in this weird in be in between zone. Another thing is that a lot of times when people are trying to learn something, they have a specific problem. And, um, I guess with, with books, it's, you kind of don't know for sure if the thing you're looking for is going to be in the book. [00:38:13] David: I mean, so my, so my book, I would not say as a beginner, it's not a book to learn how to do Rails. It's like you already kind of know Rails and you want to like learn some comprehensive practices. That's what my book is for. And so sometimes people will ask me, I don't know Rails, should I get your book? And I'm like, no, you should not. but then you have the opposite thing where like the agile web development with Rails is like the beginner version. And some people are like, Oh, it's being updated for Rails 7. Should I get it? I'm like, probably not because How to go from zero to rails hasn't changed a lot in years. There's not that much that's going to be new. but, how do you know that, right? Hopefully the Table of Contents tells you. I mean, the first book I wrote with Pragmatic, they basically were like, The Table of Contents is the only thing the reader, potential reader is going to have to have any idea what's in the book. So, You need to write the table of contents with that in mind, which may not be how you'd write the subsections of a book, but since you know that it's going to serve these dual purposes of organizing the book, but also being promotional material that people can read, you've got to keep that in mind, because otherwise, how does anybody, like you said, how does anybody know what's, what's going to be in there? And they're not cheap, I mean, these books are 50 bucks sometimes, and That's a lot of money for people in the U. S. People outside the U. S. That's a ton of money. So you want to make sure that they know what they're getting and don't feel ripped off. [00:39:33] Jeremy: Yeah, I think the other challenge is, at least what I've heard, is that... When people see a video course, for whatever reason, they, they set, like, a higher value to it. They go, like, oh, this video course is, 200 dollars and it's, like, seems like a lot of money, but for some people it's, like, okay, I can do that. But then if you say, like, oh, this, this book I've been researching for five years, uh, I want to sell it for a hundred bucks, people are going to be, like no. No way., [00:40:00] David: Yeah. Right. A hundred bucks for a book. There's no way. That's a, that's a lot. Yeah. I mean, producing video, I've thought about doing video content, but it seems so labor intensive. Um, and it's kind of like, It's sort of like a performance. Like I was mentioning before we started that I used to play in bands and like, there's a lot to go into making an even mediocre performance. And so I feel like, you know, video content is the same way. So I get that it like, it does cost more to produce, but, are you getting more information out of it? I, that, I don't know, like maybe not, but who knows? I mean, people learn things in different ways. So, [00:40:35] Jeremy: It's just like this perception thing, I think. And, uh, I'm not sure why that is. Um, [00:40:40] David: Yeah, maybe it's newer, right? Maybe books feel older so they're easier to make and video seems newer. I mean, I don't know. I would love to talk to engineers who are like... young out of college, a few years into their career to see what their perception of this stuff is. Cause I mean, there was no, I mean, like I said, I read books cause that's all there was. There was no, no videos. You, you go to a conference and you read a book and that was, that was all you had. so I get it. It seems a whole video. It's fancier. It's newer. yeah, I don't know. I would love to hear a wide variety of takes on it to see what's actually the, the future, you know? [00:41:15] Jeremy: sure, yeah. I mean, I think it probably can't just be one or the other, right? Like, I think there are... Benefits of each way. Like, if you have the book, you can read it at your own pace without having to, like, scroll through the video, and you can easily copy and paste the, the code segments, [00:41:35] David: Search it. Go back and forth. [00:41:36] Jeremy: yeah, search it. So, I think there's a place for it, but yeah, I think it would be very interesting, like you said, to, to see, like, how are people learning, [00:41:45] David: Right. Right. Yeah. Well, it's the same with blogs and podcasts. Like I, a lot of podcasters I think used to be bloggers and they realized that like they can get out what they need by doing a podcast. And it's way easier because it's more conversational. You don't have to do a bunch of research. You don't have to do a bunch of editing. As long as you're semi coherent, you can just have a conversation with somebody and sort of get at some sort of thing that you want to talk about or have an opinion about. And. So you, you, you see a lot more podcasts and a lot less blogs out there because of that. So it's, that's kind of like the creators I think are kind of driving that a little bit. yeah. So I don't know. [00:42:22] Jeremy: Yeah, I mean, I can, I can say for myself, the thing about podcasts is that it's something that I can listen to while I'm doing something else. And so you sort of passively can hopefully pick something up out of that conversation, but... Like, I think it's maybe not so good at the details, right? Like, if you're talking code, you can talk about it over voice, but can you really visualize it? Yeah, yeah, yeah. I think if you sit down and you try to implement something somebody talked about, you're gonna be like, I don't know what's happening. [00:42:51] David: Yeah. [00:42:52] Jeremy: So, uh, so, so I think there's like these, these different roles I think almost for so like maybe you know the podcast is for you to Maybe get some ideas or get some familiarity with a thing and then when you're ready to go deeper You can go look at a blog post or read a book I think video kind of straddles those two where sometimes video is good if you want to just see, the general concept of a thing, and have somebody explain it to you, maybe do some visuals. that's really good. but then it can also be kind of detailed, where, especially like the people who stream their process, right, you can see them, Oh, let's, let's build this thing together. You can ask me questions, you can see how I think. I think that can be really powerful. at the same time, like you said, it can be hard to say, like, you know, I look at some of the streams and it's like, oh, this is a three hour stream and like, well, I mean, I'm interested. I'm interested, but yeah, it's hard enough for me to sit through a, uh, a three hour movie, [00:43:52] David: Well, then that, and that gets into like, I mean, we're, you know, we're at a conference and they, they're doing something a little, like, there are conference talks at this conference, but there's also like. sort of less defined activities that aren't a conference talk. And I think that could be a reaction to some of this too. It's like I could watch a conference talk on, on video. How different is that going to be than being there in person? maybe it's not that different. Maybe, maybe I don't need to like travel across the country to go. Do something that I could see on video. So there's gotta be something here that, that, that meets that need that I can't meet any other way. So it's all these different, like, I would like to think that's how it is, right? All this media all is a part to play and it's all going to kind of continue and thrive and it's not going to be like, Oh, remember books? Like maybe, but hopefully not. Hopefully it's like, like what you're saying. Like it's all kind of serving different purposes that all kind of work together. Yeah. [00:44:43] Jeremy: I hope that's the case, because, um, I don't want to have to scroll through too many videos. [00:44:48] David: Yeah. The video's not for me. Large Language Models [00:44:50] Jeremy: I, I like, I actually do find it helpful, like, like I said, for the high level thing, or just to see someone's thought process, but it's like, if you want to know a thing, and you have a short amount of time, maybe not the best, um, of course, now you have all the large language model stuff where you like, you feed the video in like, Hey, tell, tell, tell me, uh, what this video is about and give me the code snippets and all that stuff. I don't know how well it works, but it seems [00:45:14] David: It's gotta get better. Cause you go to a support site and they're like, here's how to fix your problem, and it's a video. And I'm like, can you just tell me? But I'd never thought about asking the AI to just look at the video and tell me. So yeah, it's not bad. [00:45:25] Jeremy: I think, that's probably where we're going. So it's, uh, it's a little weird to think about, but, [00:45:29] David: yeah, yeah. I was just updating, uh, you know, like I said, I try to keep the book updated when new versions of Rails come out, so I'm getting ready to update it for Rails 7. 1 and in Amazon's, Kindle Direct Publishing as their sort of backend for where you, you know, publish like a Kindle book and stuff, and so they added a new question, was AI used in the production of this thing or not? And if you answer yes, they want you to say how much, And I don't know what they're gonna do with that exactly, but I thought it was pretty interesting, cause I would be very disappointed to pay 50 for a book that the AI wrote, right? So it's good that they're asking that? Yeah. [00:46:02] Jeremy: I think the problem Amazon is facing is where people wholesale have the AI write the book, and the person either doesn't review it at all, or maybe looks at a little, a little bit. And, I mean, the, the large language model stuff is very impressive, but If you have it generate a technical book for you, it's not going to be good. [00:46:22] David: yeah. And I guess, cause cause like Amazon, I mean, think about like Amazon scale, like they're not looking at the book at all. Like I, I can go click a button and have my book available and no person's going to look at it. they might scan it or something maybe with looking for bad words. I don't know, but there's no curation process there. So I could, yeah. I could see where they could have that, that kind of problem. And like you as the, as the buyer, you don't necessarily, if you want to book on something really esoteric, there are a lot of topics I wish there was a book on that there isn't. And as someone generally want to put it on Amazon, I could see a lot of people buying it, not realizing what they're getting and feeling ripped off when it was not good. [00:47:00] Jeremy: Yeah, I mean, I, I don't know, if it's an issue with the, the technical stuff. It probably is. But I, I know they've definitely had problems where, fiction, they have people just generating hundreds, thousands of books, submitting them all, just flooding it. [00:47:13] David: Seeing what happens. [00:47:14] Jeremy: And, um, I think that's probably... That's probably the main reason why they ask you, cause they want you to say like, uh, yeah, you said it wasn't. And so now we can remove your book. [00:47:24] David: right. Right. Yeah. Yeah. [00:47:26] Jeremy: I mean, it's, it's not quite the same, but it's similar to, I don't know what Stack Overflow's policy is now, but, when the large language model stuff started getting big, they had a lot of people answering the questions that were just. Pasting the question into the model [00:47:41] David: Which because they got it from [00:47:42] Jeremy: and then [00:47:43] David: The Got model got it from Stack Overflow. [00:47:45] Jeremy: and then pasting the answer into Stack Overflow and the person is not checking it. Right. So it's like, could be right, could not be right. Um, cause, cause to me, it's like, if, if you generate it, if you generate the answer and the answer is right, and you checked it, I'm okay with that. [00:48:00] David: Yeah. Yeah. [00:48:01] Jeremy: but if you're just like, I, I need some karma, so I'm gonna, I'm gonna answer these questions with, with this bot, I mean, then maybe [00:48:08] David: I could have done that. You're not adding anything. Yeah, yeah. [00:48:11] Jeremy: it's gonna be a weird, weird world, I think. [00:48:12] David: Yeah, no kidding. No kidding. [00:48:15] Jeremy: that's a, a good place to end it on, but is there anything else you want to mention, [00:48:19] David: No, I think we covered it all just yeah, you could find me online. I'm Davetron5000 on Ruby. social Mastodon, I occasionally post on Twitter, but not that much anymore. So Mastodon's a place to go. [00:48:31] Jeremy: David, thank you so much [00:48:32] David: All right. Well, thanks for having me.

Amal & Nick are joined by Saron Yitbarek (developer, podcaster, community leader & serial entrepreneur) to catch up and discuss her latest project: Not A Designer We discuss all the ins & outs of tech entrepreneurship & the challenges of building something new in today's saturated market. Tune in for a behind-the-scenes look at how she does it & get a sneak peek on what's possibly next! (Spoiler Alert: we brain stormed it here)

Amal & Nick are joined by Saron Yitbarek (developer, podcaster, community leader & serial entrepreneur) to catch up and discuss her latest project: Not A Designer We discuss all the ins & outs of tech entrepreneurship & the challenges of building something new in today's saturated market. Tune in for a behind-the-scenes look at how she does it & get a sneak peek on what's possibly next! (Spoiler Alert: we brain stormed it here)

Mike and Danny Sheridan from Fern chat about updates to Fern: client library SDK codegen, and their great new docs site generator tool. Fern - https://buildwithfern.com/ Danny Sheridan - https://www.linkedin.com/in/sheridandanny/ Amazon Smithy Palantir Conjure Fern OSS on GitHub Cohere APIs You Won't Hate: Make your API Idempotent Fern Careers

An enhanced podcast about all things Macintosh. For Mac geeks, by Mac geeks. Episode 880. New M3 Macs. Apple 2023 Q4 earnings results. Apple goes bug hunting. Vision Pro sneak peek. iPad updates planned for 2024. External disk cataloging. USB-C Dock vs Hub. More Time Machine space. Cha cha changes. Special thanks to our sponsors: Zocdoc SimpliSafe Shownotes in: HTML or OPML Subscribe to the Podcast Feed or Get the MP3

Mon, 13 Nov 2023 16:45:00 +0000 https://jungeanleger.podigee.io/1156-30x30-finanzwissen-pur-folge-24-pensionskassen-und-private-wollen-nicht-mehr-austro-aktien-werden-finally-zur-satire 04677ed6899fe4c8399ca66692fba1fd In Folge 24 geht es um unsere Pensionskassen, die so gut wie gar nicht mehr in den österreichischen Aktienmarkt veranlagen, obwohl sie dürften, was nicht nur die FMA, sondern auch Wolfgang Matejka wundert. Und dann geht es um die Privaten, die nicht wollen, weil es die Wertpapier-KESt gibt. Ich spreche mit Finanzminister Magnus Brunner über das Noch-Immer-Fehlen der versprochenen Wiedereinführung der einjährigen Behaltefrist und er lässt auch in seine Idee des Vorsorgekontos blicken. Brunner hat es schwer, denn er hat diesen steuerlichen Irrweg 2011 nicht verbrochen, mit den Grünen geht jetzt Hochkompliziertes bis gar nichts, aber alle hoffen auf ihn. Zum Schluss kommen sogar Kabarettisten zu Wort. I am from Austria ist am Kapitalmarkt teilweise zur Satire geworden. Magnus Brunner im Börsepeople Podcast: https://audio-cd.at/page/podcast/4966/ https://www.bmf.gv.at Podcast Finance Friday: https://www.bmf.gv.at/presse/podcast.html Was verdienen Österreichs Haushalte mit ihrem Ersparten? Zu wenig: https://www.raiffeisenresearch.com/servlet/NoAuthLibraryServlet?action=viewDocument&encrypt=27fbc540-9d2e-4f95-8c74-379089a4406f&mime=HTML&id=replaceme@bluematrix.com About: 30x30 Finanzwissen pur ist die aufbauende Börse-EinsteigerInnen-Serie für Österreich. Host Christian Drastil mixt dafür Aktiensparen und -investments mit Home Bias. Gesendet wird auf audio-cd.at von Woche 23/2023 bis Woche 52/2023 jeden "Thank God it`s Monday" um 18 Uhr, 30 Folgen a 30 Minuten. Es wird hier unabhängig vom Tagesgeschehen produziert, ein späterer Einstieg ist immer möglich, chronologisches Hören der Folgen wird empfohlen. Supporter von "30x30" sind Uniqa, dad.at, Rosinger Group, Immofinanz, Do&Co, Addiko Bank VAS; ÖPWZ Finanzlehrgänge, EXAA und FH St.Pölten, sowie inhaltlich auch FMA, Wifi Wien und Neos Lab. Den Jingle habe ich mit der Opernsängerin Ruzanna Ananyan aufgenommen. Bewertungen bei Apple (oder auch Spotify) machen mir Freude: https://podcasts.apple.com/at/podcast/audio-cd-at-indie-podcasts-wiener-boerse-sport-musik-und-mehr/id1484919130 . Risikohinweis: Die hier veröffentlichten Gedanken sind weder als Empfehlung noch als ein Angebot oder eine Aufforderung zum An- oder Verkauf von Finanzinstrumenten zu verstehen und sollen auch nicht so verstanden werden. Sie stellen lediglich die persönliche Meinung der Podcastmacher dar. Der Handel mit Finanzprodukten unterliegt einem Risiko. Sie können Ihr eingesetztes Kapital verlieren. Und: Bewertungen bei Apple (oder auch Spotify) machen mir Freude: https://podcasts.apple.com/at/podcast/audio-cd-at-indie-podcasts-wiener-boerse-sport-musik-und-mehr/id1484919130 . 1156 full no

Julien Danjou is the founder of Mergify - a tool that helps merge code safer and faster. Summary (auto-generated): How do you split your time between work and marketing? 0:00 Julian splits 50% of his time between building the product and the other 50% doing marketing and bringing people to the product. Julian talks about mergerfi. Where do you start with product development? 1:23 The goal is to solve a problem for an engineer. They co-founded Mirchi Fi with Mary and wrote their own tool. The role of time is a lot of time. The importance of doing demos and showing the product around to the team, and how that has changed over time. How the product is simple and there are a lot of viable options around it, but it's hard to think about all the tiny details. How did they get started? 5:08 They both started with a full-time job and moved from a platform to get up. They felt naked without any of their tools. They wanted to build their own tools. They found a first rate customer, pitch.com, and then found more startups willing to use a merge request tool. One of the challenges of being a bootstrapped company is that they only have two hours per week to work on the tool. It is easy to not get good at making decisions when you can do everything, but in air quotes, do everything. How long did it take to write the first dashboard? 10:07 Before people started using it internally, they did most of the grunt work of writing the first version. The first version was a mvp. The first dashboard they wrote was like HTML and the bootstrap framework, which was pretty bad, but it was good enough. The first version of the product is the only thing that is going to be out in front of users or customers. The importance of being an entrepreneur-minded person. When they found the first customers, they decided not to build a company right away, but to focus on building a few hours a week into bots. The real trap. Marketing and getting the word out. 16:00 The root problem is that nobody knows about you because you are not doing marketing. You have to go with the event if you have a competitor or inspire something. It is easy to build the things for a year or so, especially when you are a developer. Not everything works, but what works well is open source projects. For example, amazon is using lodgify on their open source project. One of their biggest customers was using one of the engineer's projects on github.com, and they talk to their manager about it. Marketing and marketing budget. 20:30 Marketing is a lot of different channels that they can use, and they have tried almost everything to see if it works, and if it doesn't work, they try to future-harm. They try to provide value for free to open source users and projects and are happy to do that. Adding value in open source is about saving time and giving time to most open source projects using a merge tool. If a company is new to open source, they need a tool to help them with a workflow tool, marketing, etc. How did you find out about rescue? 25:36 The number of people using rescue is small. There are very small projects with just one or two people mentioning it to project being run by 50 or 100 person behind. The main goal is to actually work on the open source projects, not start a new one. Redhat was working on an open source project with Eddie when they started. Redhat is a great leverage for building a company. One takeaway for a dev tool founder, be strict about splitting 50% of your time between building the product and doing the fun stuff.

JS Party listeners and panelists celebrate great moments from the last 100 episodes! You'll hear from 14 of our favorite humans (and 1 horse) across 11 episodes. Here's to our first 300 episodes and the next 300 as well.

JS Party listeners and panelists celebrate great moments from the last 100 episodes! You'll hear from 14 of our favorite humans (and 1 horse) across 11 episodes. Here's to our first 300 episodes and the next 300 as well.

It's the 19th episode of our "Thinking the Unthinkable" series and today's (ambiguous)  topic is... "Is 20 years too long in web tech?". Full of our usual British cheerfulness, we are celebrating WordPress's 20th birthday year with a title implying its potential demise. This episode is not about predicting the future of WordPress. It's because we have never had a chat dedicated to why some web tech flourishes (as WordPress certainly did), and some die. We cover the following: The last 30 years of the web (gosh, it's a real adult now). Is growth and demise in tech a matter of luck and unpredictable? The fundamental web languages, and how they lasted. HTML and CSS are safe, aren't they? But... frameworks and CMS's are vulnerable. There's a lot more in this episode as well, so check it out...

Join us for an insightful episode of Ruby for All, where Andrew and Julie have a discussion with special guest, Jerimie Lee, a Senior Product Designer at Codecademy. Jerimie shares his journey into the world of EdTech, and his experiences in the health tech industry. The conversation touches upon the evolution of design roles, the importance of understanding product mechanics, and the differing experiences of product and UI/UX designers. Jerimie also delves into the significance of accessibility in modern design, the iterations within the product design process, and the necessity of effective communication between designers and engineers. Listen in to learn more about Jerimie's tips for successful designer-developer collaborations and his take on evolving product design trends. [00:00:51] Jerimie introduces himself, describes his role and mentions his previous experience in health tech and marketing, and his previous role at Dispatch Health. [00:01:49] Andrew asks about the difference between a product designer and UI/UX designers. He explains that product designers focus on both user experience and the product development environment, and Andrew and Jerimie discuss the role evolution. [00:04:53] Julie asks what it takes to become a UX/UI designer/ product designer. Jerimie explains that there are many ways, and he shares how he came into design. [00:06:40] Andrew shares his background in graphic design and how it influences his work as a developer. They discuss the advantages of developers having design knowledge. [00:08:41] Julie appreciates Andrew's design input and discusses her challenges as a non-designer. Jerimie shares his opinion on learning design principles. [00:09:53] Jerimie suggests that understanding basic design principles can go a long way. He mentions the Nielson Norman Group's, “10 Usability Heuristics for User Interface Design,” as a helpful resource. Andrew and Jerimie discuss the 80/20 principle and the subjectivity of design. [00:11:50] Jerimie discusses the importance of designing for web and digital interfaces and how they more rules compared to print.  He mentions accessibility guidelines and how they influence design decisions, and he emphasize the value of building efficient systems and making things work from a usability perspective. [00:12:42] Jerimie and Andrew discuss the growing importance of accessibility in design and Jerimie mentions that Codecademy is working on accessibility tickets.  Andrew shares his experience with discussing HTML specs with designers and engineers.  [00:13:43] Jerimie emphasizes the importance of designers understanding semantic HTML and technical constraints. Andrew and Julie share their perspectives on designers and developers collaborating effectively. [00:16:35] We hear about some challenges of communication when engineers may not be fully aware of the design and product process. Jerimie shares an example of engineers providing negative feedback during the exploratory phase. Julie talks about the impact of such feedback on team dynamics. [00:18:29] Jerimie emphasizes the importance of open-ended and constructive feedback from engineers and discusses the need for soft skills in communication. [00:19:54] Jerimie mentions the value of understanding technical limitations and finding solutions that circumvent them. Andrew and Julie share their approaches to conveying technical limitations when collaborating with designers. [00:22:27] Julie acknowledges her lack of front-end technical knowledge and how she and Jerimie often compromise when discussing detail, and Andrew ends to explain technical details to designers to show respect and maintain clear communication. [00:23:15] Jerimie discusses how engineers should approach designers when struggling with their designs. He encourages engineers to seek help and not give up too easily. [00:24:15] Some great advice from Jerimie for designers on how to communicate with developers includes building technical competence and being open to iteration and simplification in the design process. [00:25:38] Julie and Andrew share their perspectives on the process of iterating, and Andrew shares his perspective on the importance of having a designer on the team. He highlights the role of designers in standardizing and improving UI and how collaboration with designers can enhance the developer's work. [00:28:20] Julie talks about how the absence of a designer negatively impacted their team's direction and development, but having a designer significantly improved their work. Jerimie expresses his appreciation for the collaboration with engineers at Codecademy, and Andrew discusses the importance of mutual respect and collaboration between designers and developers. [00:32:16] Why did Andrew chose to work with Rails over interaction design? He mentions that he has a quantitative brain, and that Rails offers better financial opportunities. [00:32:47] Jerimie encourages engineers to give feedback on design and emphasizes the value of shared ownership between designers and developers. Panelists:Andrew MasonJulie J.Guest:Jerimie LeeSponsors:HoneybadgerGoRailsLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. WebsiteJerimie Lee WebsiteJerimie Lee LinkedInCodecademy10 Usability Heuristics for User Interface Design-Nielsen Norman Group

Jamon Holmgren is the founder of Infinite Red, a consultancy specializing in React Native. He discusses his journey and insights into technology and leadership and highlights how Infinite Red stands as a testament that businesses can be run ethically while still achieving success. The conversation shifts to leadership styles and the principle of "one-minute praise" from the book "One Minute Manager." Both Jamon and Will agree that acknowledging others' efforts openly can make a significant difference, enhancing leadership skills and building stronger relationships. Will points out how this simple principle has been a game-changer for him in various aspects of life, including his personal relationships. Towards the end, the focus turns to motivation and long-term strategy. Jamon is driven by his enthusiasm for learning and the thrill of tackling diverse challenges in his consultancy work. He also shares his philosophy of keeping the company "10 degrees above the horizon," emphasizing steady, sustainable growth rather than erratic leaps and bounds. Infinite Red (https://infinite.red/) Follow Infinite Red on LinkedIn (https://www.linkedin.com/company/infinitered/), X (https://twitter.com/infinite_red), YouTube (https://www.youtube.com/channel/UCwpSzVt7QpLDbCnPXqR97-g), GitHub (https://github.com/infinitered), Facebook (https://www.facebook.com/infiniteredinc/), or Instagram (https://www.instagram.com/infinitered_designers/). Follow Jamon Holmgren on LinkedIn (https://www.linkedin.com/in/jamonholmgren/) or X (https://twitter.com/jamonholmgren). Visit his website at jamon.dev (https://jamon.dev/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Jamon Holmgren, Co-Founder and CTO of Infinite Red, a software consulting agency that specializes in React Native. Jamon, thank you for joining me. JAMON: Yeah. Thanks for having me. I really appreciate it. WILL: So, Jamon, what's going on in your life? How's everything going? JAMON: You know, things have been obviously very busy, like, I guess, pretty much everybody. You know, school has started. I have four kids, so that keeps me quite busy, going to various school events, going to volleyball, you know, bringing kids here and there, running the company. I have some side projects I'm doing. I am playing hockey. So, it just seems like every waking hour is filled with something. [laughter] WILL: I totally understand that. I have three kids of my own. So, they're a little bit younger than yours, so mine is 4, 3, and, like, 17 months, so... JAMON: Okay. Yeah, so you're just getting started. And you're doing all of the, like, physical labor associated with being a parent. WILL: Yes, yes, yes. So, I want to start there. Tell me a little bit about your kids. I know their ages are 10 to 18. JAMON: Yeah, so I have a boy, Cedric. He's actually a programmer as well. He's just starting his career. He is the oldest, and then we have three girls. We have a 15-year-old who's a sophomore in high school. And then we have a 12-year-old who's in middle school and a 10-year-old who is in fifth grade in elementary school. And it's a lot. My wife and I both came from very large families, so we're kind of used to it. And it's a lot of fun. A lot of challenges at this age, I mean, teenagers especially, you know, as they kind of all come into that same era, you know, it's more of a challenge. I guess the thing that I think about it is a lot of the skills that I learned as a young kid parent don't really translate super well to being a teenager parent. And I'm having to learn a lot of new skills. And I actually talked to a guy the other day. His kids are, I think, 32 and 28, or something like that. And he said, "Yeah, the learning never stops." [laughs] WILL: So, I'm going to ask you for the secret sauce because I'm still in the temper tantrums and those type of emotions and stuff. So, how is it different in the teenage years from the temper tantrums? JAMON: Well, I think that they can act like adults in a lot of cases, and you start thinking of them as adults, and you start developing a relationship there. But their brains are also not fully developed. And so, they will also do things that are very inexplicable, like, you'll just be like, why? Why would this be a thing? Like, I don't get it. Like, you act like an adult for half the time, and then the other half, you act like a kid. Navigating that, and the fact that they change all the time, and all the other challenges. And they're all different. Like, if we had only had one kid, you know, my boy was pretty easy. He was pretty straightforward. It would have been like, well, shoot, being a parent is pretty easy. Like, I don't know what everybody else is complaining about. Like, he never did tantrums. He was just a really quiet, you know, like, well-behaved kid and kind of went through life like that. But then, obviously, developing a relationship with him is more of the challenge because he's quieter, where with my girls, it's easier to develop the relationship, but then you [laughs] deal with a lot more volatility as well. So, they're all different. Every kid's different. It's hard to really apply that directly. I would say that the thing that I've learned the most in the last few years is just kind of continuing to be, like, even through some of the tougher times, continuing to be there, continuing to develop that relationship. A lot of times, it feels like you're not getting anywhere, but you are. It is actually happening. You just don't see it until later. WILL: I'm writing that down. That's great advice [laughter]. You mentioned hockey. Tell me about it. I've never played hockey. I grew up in the South, so we didn't have that. So, tell me about it. And you're a goalie also, correct? JAMON: Yeah, I play goalie. I didn't discover hockey...I played basketball in high school. I played four years of high school basketball. I even played a little bit at college. And I didn't really discover hockey until I moved to Southwest Washington, about an hour away from where I grew up in the coast of Oregon. When I got there, a lot of my friends that I made were playing hockey. And one friend, in particular, he was a goalie, and he had grown up in Upper Michigan. So, you know, like, he grew up playing hockey. He was a very good skater and things like that. But there was one weekend I was coming to watch him play just rec hockey. And he's like, "You know what? I can't make it. Would you want to jump in and, like, be my sub?" And it was just a pick-up game. So, it wasn't like there was anything on the line. And I was like, "All right, I'll give it a try." You know, put on the gear. He showed me what to do to put on the gear. He kind of gave me some tips. Like, in the living room where we were, he was, like, showing me how to play. We were, like, I would say, 19, I think. Nineteen years old, something like that. Anyway, I show up, and I put on the gear, and I go out there. And I actually had a decent game, considering I barely knew how to skate and barely knew how to do anything. But I'm kind of big; I'm six foot four, almost six foot five. And having all that gear and everything, I filled up a lot of the net. And it wasn't a very high-level game, so I did pretty well. And after that, the team was like, "Well, we'd love to have you back." And then my friend really was not interested in continuing, so he was like, "You can have it, like, just roll with it." I kept playing for about three years, and then, I don't know, I took over a decade off. The team dissolved. It wasn't even a league team. It was just, you know, pick-up hockey. And then a friend called me and was like, "Hey, I'm starting up a game. It's going to be Finnish Americans," because I'm half-Finnish myself. "So, it's going to be all Finnish Americans. We're going to call it the [Foreign language]," which is the Finnish boys in sort of Finnish. It's not exactly supposed to be like that in Finnish. Anybody listening who's Finnish is going to be like, "Yeah, that's bad Finnish." But it kind of means Finnish boys or Finland boys. And we put together the team, and I've been playing for the last three-plus years. It's been kind of, like, a rec league team. We've won the championship four times, which was really fun. This year, I'm actually playing in two leagues. I'm playing in rec league, and I'm also playing the next league up, so a little bit faster, better skaters, better shooters, things like that. And I just love it. It's so much fun. WILL: Wow, that's amazing that you started later and that you're still playing it. Because when I look at hockey, I'm like, that's really hard. I don't know if I could do that. I can skate. I can't stop. JAMON: [laughs] WILL: Like, I can get a lot of speed [laughs]. But it's just something about turning sideways and thinking I'm going to fly over the skates. JAMON: [laughs] WILL: And yeah, it's a whole thing [laughs]. Is goalie harder than playing any of the other positions? JAMON: I would say it's different. Like, I don't have to be as good of a skater, you know, things like hockey stops are still not supernatural for me. I don't skate backwards super-fast. You know, I'm not a fast skater in general. But the difference is, of course, you have to be reading the flow of the game. You have to know the body language of the players that are coming at you. You have to kind of see what's happening. At the end of the day, lots of things can happen, so you try to put yourself in the best position. It's a lot of, like, positional, like, where are you in the net? What does your position look like? And then, once they shoot, how do you react? Are you dropping down, or are you staying up? Are you using your glove? Are you using your blocker? Are you just trying to block with your body using your stick? Then, once the puck hits you, then what do you do? How do you control the rebound? Are you trying to cover it up and ice the puck so they do a face-off? Are you trying to kick it out to one of your skaters? And then, once that happens, you have a little bit of a rest, hopefully, while they're down on the other side. But you're continually alert and watching to see what's going to develop because it could be a breakaway. And then it's just you and the skater and trying to anticipate what they're doing and try to make it so that they have to make a play. Like, just be big, be in position. Don't get out of position. Don't make a mistake. And I've had really great games where I've, you know, had 45 shots on me, and I've only let one in or something like that. And I've had some bad games too. I know there's one game in a championship where they only had six shots on me. But we ended up losing because I let in two, so that was not a fun game. I only had six opportunities, and I failed on two of them. But that happens, and so you just have to be mentally tough. WILL: Wow, that's amazing. The limited knowledge of hockey...I'm going to assume here, so I hope it's right. With you being 6'4, 6'5, I'm guessing that the five-hole, if I'm correct, was probably your toughest position to defend. JAMON: You know, you would think so. And just for the audience, the five-hole is, like, between your legs, you know, the puck going between your legs underneath. But I play a style...a little bit older style of goalie because that's what I watched. You know, in, like, the early 2000s, I watched Patrick Roy of the Colorado Avalanche, one of the greatest goalies of all time, and he played what's called a butterfly style. So, as the play develops, you're standing, but then you go down fairly early, and you're protecting the bottom. You have your stick in front of you protecting the five-hole, and you have your legs, you know, spread out. So, I used my height really more for blocking as I'm down rather than standing because when I'm standing, I'm above the net. It's better for me to get down. And I think that that's worked out pretty well. You know, Patrick Roy was a pretty big goalie as well. Most modern goalies play a more hybrid style. But, you know, we could get into all that. I'm a big kind of hockey nerd in this way. But that's what I do. I play butterfly, so most of the time, people don't beat me five-hole; when they do, it's usually they're picking a corner. WILL: Wow. Now that you've painted the picture, I can see how that's smart because you do have the goal, I mean, the gloves plus the stick and then your height. Yeah, I can see how...that's smart. That's very smart [laughs]. JAMON: Yeah, that's right. Yeah, that's kind of the goal. And also, because I wasn't a great skater, it sort of played into it as well, playing down on the ice where I was just more comfortable that way. It's worked out. I've had a pretty decent record over my career here [laughs]. WILL: That's awesome. Well, let's transition a little bit into consultant agencies. You've been doing it for 18 years. Tell me about that. How did you get started? JAMON: Well, when I started, I was working in construction. I was working for a home builder. And, you know, everybody I knew pretty much worked in construction, including my dad, who owned a business. And I went on my own. I had always dreamed of owning my own business, but I didn't start really thinking about websites. I was coding. I loved coding, and I was coding since I was 12. So, when I got to 23 years old, I thought, I'll start a business, and I'll do home design because that's what I was doing for the builder was, I was drawing homes. I was designing homes and remodels and things like that. And so, I started it doing that. But I also needed a little bit extra work. I didn't have enough work. Like, I had people, you know, sending me work, you know, home design and whatnot, but I didn't have quite enough. So, I would also build websites on the side, PHP and HTML, MySQL, and JavaScript. And I just sort of continued to do that. But in 2008, there was the housing crisis, and all of the design work for homes just dried up. There wasn't much there. In fact, it actually really dried up in 2007 because things kind of started a little early for designers. And so, I was like; I got to do something to stay busy. I've got a wife. I've got a young kid (Actually, at that point, I had two kids.), and I need to make sure that I'm staying busy. And so, I really ramped up trying to find work, you know, as a programmer, as a web developer. And there were plenty of companies at that time that were really trying to drum up business. So, they were putting money into their websites trying to get new projects, and they were all construction companies. And so, that's how I started. And I started doing more things like internal web apps for managing orders and managing sales leads, and that sort of thing. And that led me into web apps and eventually to Ruby on Rails, which became sort of my bread and butter for a while. As I was doing Ruby on Rails, you know, obviously, the iPhone was out, but the iPad came out. And I was more of an Android guy at that point. But I bought an iPad because it looked really cool, and my dad had one. When I started playing around with it, I'm like, I need to build apps for this. This is super cool. So, I took some Stanford courses online, which you could do back in those days, iTunes U, and learned how to use Objective-C. This was previous to Automatic Reference Counting and stuff. So, you had to manage your own memory, and this was a lot of manual work; very different environment than JavaScript, and PHP, and Ruby. But I actually enjoyed it quite a bit and then eventually transitioned into React Native later. But really, getting over to mobile and that sort of thing was...once I found mobile, I really didn't want to do web anymore. Mobile is what I really enjoy doing. WILL: Wow, I love that. If I'm following you correctly, you said in 2007, that's kind of when everything dried up. So, you were almost forced to find something different, correct? JAMON: Yeah, that's right. I mean, I kind of sat around feeling sorry for myself for a while. And then I was like, well, it's my business. I got to figure out what to do. It's not anybody else's fault. Like, you know, it doesn't matter that this is forces out of my control. I do have control. I have the ability to go in there and figure out, okay, what do I do next? Well, I know how to program, and it seems like people want me to program. So, let's lean into that. WILL: Wow. I love that. Because it's funny, that's how I got started in programming. I lost my job. And I was working at Buckle, the clothing store. If you know me, that is not me at all, like, at all [laughter]. I love gym shorts and athletic clothes. Like, fashion is not my thing. It's just not. So [laughs], I got into programming because I was just struggling. And it was a very pivotal moment in my life. And I'm thankful that I lost my job. Losing your job is just hard, and I think it makes you rethink things. JAMON: Yeah, absolutely. It was a growth moment for me as well, one of many. But that was definitely a point that I look back on and say, I mean because I can actually point at almost the day when it all dried up. It was, like, April 2007. And my uncle had been sending me a lot of work, you know, he had extra work. He didn't have barely enough for himself anymore at that point. And I finished up my last project, and he's like, "I don't have anything else." And I had some other clients as well and called them up, and they were like, "No, we don't have anything. Like, nobody is buying right now." And it just kept going like that. And it was weird because 2005, 2006, most of 2007, it felt like things were really rolling, but it just dried up all at once. And so, I was really lucky that I did end up getting a bunch of web work to do in 2008. I was still doing home design till probably late 2008, 2009. But then I eventually just hung that up and was like, okay, this is over. I'm definitely focusing on programming. WILL: Wow, how was the initial traction when you moved into ramping up the web development? JAMON: It was really good because it didn't take much to keep me busy. And I ended up getting some big contracts from, like, a cabinet manufacturer was a big one. I did some other things as well. And I ended up hiring my first employees in 2009. So, really, less than two years later, I was starting to hire employees. And I just hired, like, junior developers who had barely learned to code and taught them to code. So, I hired probably, over the years, next few years, like, ten programmers, many of whom are actually still with me today, and I taught them to code back in the day. And as time went on, they became senior and really high-level programmers who are now leading projects for big companies that you've heard of. But they started with me building, you know, PHP and MySQL and whatnot for small, like, regional construction companies. And we learned together. So, it was definitely a progression you can go look back and see. WILL: Yeah, I saw a tweet that you tweeted, and I loved it because I totally understand. JAMON: [laughs] WILL: And so, I'm glad you mentioned the junior devs and stuff. The tweet that I'm talking about was, "I got into this industry to code; ended up becoming a founder because I was the only person who would hire me." JAMON: [laughs] WILL: I want to ask you about that. [laughter] JAMON: Yeah, it's really that I grew up in a small logging town, like, very tiny logging town in Northwest Oregon. I didn't know...I knew one programmer, and the guy was, like, an incredible genius. And I just thought that that was the only way that you could professionally be a programmer was to be an incredible genius. I was coding, but I was, like, coding games, you know, in QBasic. And so, for me, every time I looked around, it was just, like, construction, or logging or, you know, blue collar, like, working at a mill. Like, these were the things that I saw around me. And so, that was the path I went. And I didn't really think of using this passion that I had for coding to turn it into, like, actual money. And when I did start thinking about it, I was like, I don't know anybody who does software. Like, even when I moved to Southwest Washington, I was closer to Portland. But I thought you had to have a CS degree, and I didn't have a CS degree. So, I was like, okay, well, I'll start my own business then, and that will be the thing that kind of leads me into tech. And that's what ended up happening. And it's kind of funny because I did go to, you know, one semester of community college for basketball and for...until I got cut. And then I studied some things there. But I never finished for the community college. What's kind of cool, though, is today, I'm actually on their, like, tech advisory committee. Like, they actually have me advising their professors on the current state of tech, which is kind of cool. WILL: Wow, that is really cool. It is interesting because I remember when I first started out and that feeling of probably over 300 applications just trying to get a job. And it was just hard. And my first job, to be honest, I think it was because of networking is why I got the job. If I didn't know the person that introduced me to the company, I probably wouldn't have gotten the job, if I'm being honest. But I am very sympathetic for junior devs anytime. If a junior dev asks me a question, I will take time, help them out. Because I remember...it's very hard as a junior dev trying to get that first job. So, when you said that, I was like, yeah, I can see your heart towards junior devs. JAMON: Absolutely. That's where I started. You know, the first developers that I hired were all juniors. We don't hire juniors anymore because of the style of business that we are. But I miss that. I miss that to some degree. We really can't. And we've looked at it from just about every angle. But I did my time [laughs]. I spent a lot of hours teaching junior developers when I could have done it quicker myself. WILL: Definitely. Like, you end up losing some money when you do a junior dev and you're hiring for the future. So, like, in a consultant agency, I totally understand that, yeah. JAMON: Yeah, absolutely. MID-ROLL AD: Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. WILL: So, I want to ask you about the transition from ClearSight Studio to Infinite Red. How did that happen? JAMON: ClearSight was my first company. And it sort of evolved from being a, you know, a home design/website company to just a website and web app company, and then mobile apps. And, at a certain time, we had, I think, around 12 employees, something like that. I had a design department. We were building websites and whatnot. And I was really interested in iOS development. That was really my passion. And so I actually ended up working on some open source with iOS developers across the globe and then got invited to a conference down in San Francisco in 2014. And I went and gave a talk there. It was my first tech conference that I'd ever been to, much less given a talk, and I was the first talk [laughs]. So, that was kind of an interesting little anecdote there. And as I did it, I got to know some other developers. I had one in particular, Todd Werth, who I really hit it off with, and we ended up chatting a lot after the conference. And it felt like he and I had a very similar outlook. And he had an iOS agency. That's all they did. Well, 2015 rolls around, and I had had some rough times toward the end of 2014 in terms of the business, and I was kind of complaining to Todd. He had had some issues as well, and we started commiserating. And he's like, you know, he just started joking. I still have this conversation in Slack way back if I go look. And he's like, "Well, maybe we should just merge our businesses together," because it felt like we had maybe complementary skills. And we had a similar outlook on what we wanted from our businesses. And so, we ended up eventually solidifying that. I flew down there, talked to him and his business partner, Ken, at the time. We ended up making that happen later that year. So, just a few days ago, October 1st was our eighth anniversary running the companies, running the new company, the merged company, which is Infinite Red. So, that was kind of how that all came together. Eventually, Ken left, and we had a new business partner who was our top employee buy-in; that's Gant Laborde. And so, there are still three owners. We have three directors and then the rest of the team. We're about 30 people altogether, and we focus entirely on React Native. WILL: Wow, congratulations on eight years. That's a lot. That's amazing. JAMON: Yeah, thank you. I was just thinking the other day that I ran ClearSight for ten years. Infinite Red is getting close to how long I ran my first business. And, like, my youngest is, like I said, 10. So she was only two years old when I merged the company. She does not remember my old company, which is weird to me. [laughter] WILL: Wow. So, can you walk me through your decision to go here with React Native and specialize in that? Because it sounds like right around the time when React Native was created, and people started using it in production. JAMON: That's right. The iOS technology that we had sort of bonded over at that conference was called RubyMotion. But in 2015, the founder ended up going to work for Microsoft for a while and then went back to Apple. He had been from Apple before. So, it was sort of going down. And we were looking for a different technology, both of our companies were, and then, of course, the merged company. React Native looked interesting, but it didn't have an Android version yet. But then, in September of 2015, Android came out, so it was iOS and Android. So, we were able to take a look at that one month before we ended up solidifying the actual merger. So, basically, day one, October 1st, 2015, we were, like, we are now doing React Native for mobile, but we kept doing web. We kept doing Ruby on Rails. We did some Elixir. We did some Elm. We did some...I think we had some old Ember stuff going on. We had all kinds of things going on. But over time, we got more and more traction with React Native because that's really where our interest was. And so, we ended up saying, okay, well, this is where we really want to be. It took us a few years. It took us probably five years, six years, something like that, to really develop the confidence to say, "Hey, this is all we want to do," because it's a risk. Like, you put yourself on one technology. We had that before with the other technology that went down. But we had the confidence that we knew we could step off of a sinking ship onto another one if we needed to. So, we said, "You know what? Let's do this." And I got to give my co-founder, Todd, a lot of credit because he was the first one to say, "Let's go all React Native. Anywhere that React Native is, React Native is on a lot of different platforms. You can do tvOS. You can do Mac. You can do Windows. You can do web with React Native web, all kinds of things. So, let's just focus on React Native. Our team will just focus on that. We will only hire React Native developers. All of our marketing is going to be around React Native. Let's just focus on that." And it ended up being a great call. We did that. We made that happen. And for probably the last, I would say, three, four years, something like that, that's all we've been doing. WILL: So, what's your opinion on, I guess, the argument that's being held right now with native iOS and Android, even the Flutter, and I think Ionic is the other one that I've heard of, versus React Native? What's your pitch on React Native over those? JAMON: There's definitely reasons to use any of those. But I wrote this article a while back. It was specifically about Flutter, but I think it applies to a lot of the other competitors as well. The title of the article was provocatively titled, "Flutter Is Better Than React Native in All the Ways That Don't Matter." And the idea behind this is that, yes, Flutter gets a lot of things very right. A lot of their developer experience is actually better than React Native; some is worse, but, you know, some is better. But really, when it comes down to it, the things that matter are more business level. React Native is good enough. It's like native views. So, you have the native performance. With Hermes, you have really good performance in JavaScript. So, you know that you can get really high-level JavaScript performance. You can ship JavaScript, which really helps because then you can bring in JavaScript developers, and specifically React developers. So, a lot of companies already use React. It's a no-brainer to then use React Native if you're already using React Web. It doesn't really make sense to go to Flutter. It makes maybe some sense to write it in native, but then you have to write it twice. And you have three teams. You have a web team. You have an iOS team, and you have an Android team. And you also have three codebases, and one's always lagging behind. That's always what's happening. Marketing is like, "Okay, when can we announce this?" "Well, iOS isn't done," or "Android is not done," or "Web is not done." Where if you can combine all of those things and combine just the culture of your team, then it becomes more tight-knit because everybody's working on all aspects at one time. You can take a feature, and you can build it in web, and you can build it in iOS, and you can build it Android with all the same skills. Now, there are some deeper parts of React Native. It goes really deep. But in terms of just being productive out of the gate, a React developer can be productive in week one, and that's, I think, a huge deal. So, it really comes down to is the performance and developer experience good enough? And the answer is absolutely yes. And then, secondly, like, what's the business case for React Native? Well, you can have the same developers doing iOS, Android, and web, and even if you don't, you can share techniques. You can be like, "Hey, here's this cool JavaScript thing," and the Kotlin developers aren't just like, "Ugh, you know, JavaScript." Or you can be like, "Hey, here's our TypeScript configuration across the whole codebase." You can even have a monorepo with everything in it. It just makes a lot of sense that way. And especially now with Expo, it makes it even more that way because Expo removes a lot of the barriers for web developers that they would have coming into native. So, with that in mind, I still see React Native dominating the apps that are at the top of the App Store. One of the Expo developers, Evan Bacon, has put out a bunch of tweets about, you know, like, 24 out of the top 100 food and drink apps are written in React Native, as opposed to 8 in all the other options combined other than native, you know. So, it gives a good sense that React Native is still growing and continuing to. It has a lot of steam behind it. WILL: Yeah, I totally agree with you. I'm a big React Native fan, and I do a lot of React Native work here. So, yes, totally agree with you. And one of the most frustrating things that I've come across is, I'm a big researcher, and so I'll research things, and I'm like, oh, there's an app for this. And I'm a big Android fan, so when I go to them, it's like, oh yes, I can use this app. And then it's like, no, I can't. It's only for iOS. Okay, like, you lost me as a customer. JAMON: [laughs] WILL: I was willing to pay whatever on this because I've been looking for it. So yeah, I like how you said that. JAMON: Yeah. It treats all of the platforms as first-class citizens. WILL: Yes. Yes, yes, yes. Totally agree. How does your company handle the backend? Do y'all do any of the backend, or how is that handled at Infinite Red? JAMON: We used to do that, like I mentioned. But a few years ago...we had a very, very small back-end team by then. Most of the time, and now pretty much 100% of the time, when someone comes to us, they already have a back-end team, so we work directly with them. A lot of our developers were back-end developers, and so they understand the backend really well, but they're obviously React Native specialists now. So, you know, I came from that. I did PHP. I did Ruby, Ruby on Rails, Elixir, Node, all kinds of back-end technology. So, I understand it really well as well. But yeah, we lean on our clients for that. We might partner with an agency like you folks over there at thoughtbot and have them do the backend, or just have the client, you know, come up with their own solution. WILL: Yeah, I love that, yeah. And we've done that with numerous agencies, so yeah, that's awesome. What does success look like for Infinite Red now versus, you know, six months or five years from now? Do y'all have any goals in mind that you're trying to hit? JAMON: In the Infinite Red leadership, we are currently reading John Maxwell's 21 indisputable Laws of Leadership, which is a good book. And we had this really great conversation at our first book club meeting in leadership, which John Maxwell defines success in a very different way than we do. You know, he measured it as, like, McDonald's, or Starbucks, or something like that, like, giant, becoming huge, becoming big, making tons of money. And it was sort of just implicit in the book that that was the case. We had this great talk internally. Why didn't this resonate with us? And that's because we don't really measure success that way. So, I love that question, Will, because measuring success is you really have to start there. Like, you have to start there and say, "What do we want from this?" So, ultimately, we want to build cool things with our friends. I'm a coding nerd. I want to code. I want to be in the code. That's why we're an agency. Like, if we were a product company, if we were building, I don't know, podcasting software or something, we'd have to become experts in podcasting rather than experts in React Native, or experts in TypeScript, or whatever we want to do. So, we really love code. We want to build that. We want to have an amazing family-first environment. We want to treat everybody super well. We want to have really low turnover, which we've been able to achieve. Hardly anybody leaves Infinite Red. Maybe every other year, we might lose one person. And even with those people, they tend to come back [laughs], which is a great sign. They go out and find out that, yeah, actually, Infinite Red is pretty awesome, and they come back. So, we really look for that. We really focus on that. We want that to happen. And it's really less about making the most money we can. Obviously, everybody wants to be well paid. And so, we're going to try to make sure we have a successful business in that way and that we want to be around for a long time. But, really, measuring success is less about business success and it's more about life success. It's really more about family success, being with my four kids, being there for them when they need me to be. That's why we're remote, you know, as another example. So, everything really hinges off of that. It's around happiness. It's around fulfillment. It's not around financial success. WILL: I'm a huge John Maxwell fan, by the way. JAMON: [laughs] There you go. WILL: So, yes, I love it. And I love how you explained, you know, because one of my questions I was going to ask you is about the core values, but I'm going to switch it up a little bit. So, I'm just going to say, in my opinion, I feel like there's almost leadership talk void at times, especially in the tech space. Like, we don't talk about leadership a lot. But it plays a huge part in what we do day to day. Like, you named a couple of core values and principles that you're following because of the leadership. So, for you, why is the leadership so important and I guess you can say have a seat at the table at Infinite Red? JAMON: I'm a strong believer, and I've become more of a strong believer over time, that it all starts at the top. If you don't have buy-in from your top leadership, it does not really matter what happens otherwise because they will continually undermine, and they have the power to continually undermine that. So, these core values have to apply to the top leaders. They have to be held accountable to that. And these leaders also need to be developed. So, we have three owners. We have three directors. And the three directors who are underneath us were not directors when we hired them; you know, they started out as developers. They started out as designers. They started out as project managers. But they became Director of Operations, Director of Engineering, Director of Communications. And we developed them. We poured a lot of time into them, and we continue to do that. In fact, even reading this book with them and going through that exercise is continuing to invest in them. Not that we as owners don't have growth to do; we also do. And so, we learn from them, and we learn from our team. So, you have to start there. And on that same vein, we do have some core values. We call them our foundation and our pillars. We have three foundational things, and we have four pillars. So, the three foundations are: one, we control our own destiny. We are not going to be beholden to some other company. We're not going to ride someone else's coattails. We're not going to be in a situation where someone else can kill us. And it can be easily done that way where we're in a position where, you know, we're too reliant on one whale client or something like that. We just won't do it. The second foundational thing is that we have...it's a word bonitas, which means kindness, friendliness, benevolence, blamelessness. And it's basically just being a good person to everybody and doing the right thing. And the third one is having a significant positive impact. That's why we do so much media. That's why we try to have an impact outside. And we're only 30 people, but people think we're way bigger because of how we kind of present ourselves in the world. And then our pillars all support those things, so high personal support. We support each other. We have high expectations, but we also support each other not just at work but also as a whole person. Long-term viewpoint, we think way beyond this year. We think about what is Infinite Red going to be when I retire? You know, I'm 41; that's a ways out, hopefully. But what's that going to look like? The next one is collaborative creativity. Creativity by yourself is just a solo thing. We're a team, so it has to be collaborative. We have to do it together. All our creative work, whether it's our conference, Chain React, or our work, it's all collaborative, and we love being creative. And the last thing is being pioneers, pioneering spirit. We like to be pioneers in technology. We put out a lot of open source. And we try to bring that pioneering spirit everywhere we go. And then, there's a lot of different things that kind of come out of that. For example, we have this internal saying, which is, "Don't do hard things alone." So, you have a hard thing coming up? And it could be hard in various ways. It could be a technically challenging thing. It could just be hard because of the mood you're in that day. But don't do it alone. Ask someone to help you, you know, jump in with you, pair with you. Do it together. And we love that. That's part of the high personal support and the bonitas. So, all these things come out of the foundation and pillars that we have. WILL: Wow, I love all those. I want to pick one of them out and ask you a question around it. So, you're talking about having an impact. I'm loving this conversation just talking to you. It's just been amazing. So, for you, what do you want the impact on the world to be from your perspective? JAMON: That's a hard question to answer, and it tends to be something that I think about a lot. I'm more of an opportunistic person. I react more than I plan ahead, that sort of thing. But with that said, I think that we have had significant positive impact through a lot of different ways. So, on Twitter, for example, I try to present a...and this is authentically who I am. But I try to present a positive force out there, someone who's excited and enthusiastic about the technology, who supports other people, even who you might consider competitors, for example. I just retweeted recently a Callstack thing. I mean, you might consider them a competitor. They're another React Native agency. But I love Callstack. They're great people. And I retweeted one of their really amazing resources, which is the ultimate guide to React Native performance, which, by the way, is really good. And if you do React Native, you should check it out. So, I think what goes around comes around, and I really want to have that positive impact out there. I want to give talks that inspire people. You know, I'm a nerd, and I'm going to nerd out about stuff. And I feel like that has an impact all of its own. So, that's kind of my personal side of it. And then Infinite Red is a showcase that you can run a company the right way. You can treat people the right way. And the company can be successful along our own metrics of success. WILL: So, one of my biggest principles that I've learned in life that's changed my leadership 100,000% is from this book called One Minute Manager. And I think it's called one-minute praise. And, essentially, the background behind it is, if you think something, just tell the person because so many times...and I get in my head, and I think amazing things about people, but I never say it. JAMON: [laughs] WILL: So, I want to just tell you, like, you said, the impact that you're making. You are doing that. Like, one of the reasons why I invited you on the show was because of your impact that I see that you're having on Twitter and LinkedIn and just everything that you're doing at Infinite Red. So, keep going. I want you to know that you are making a difference. I see you, and it's making a big difference in my life. JAMON: I love that, and it makes me feel great. And I appreciate you sharing that one-minute praise there. It is something that sometimes you put it out there, and you don't really know what the impact is, you know, it's sort of hidden in maybe the likes, or the replies, or whatever. As an example, I just reached out to my friend Aaron Francis last night, and I told him, "Hey, I love your videos." I don't even do the tech that he does. But I watch his videos on YouTube because I just love the vibe that he has. And I told him that. I was like, "You're doing a great job. You're being a very good advocate for your company." And I agree with you; I think that just taking the moment to reach out and say, "Hey, I think you're doing good work," it encourages people to do more of it. So, I appreciate it a lot, Will. That's really nice of you to say. WILL: Yeah, definitely. If you can go back, what is some advice that you would give yourself? We could do both at the beginning when you did ClearSight and whenever you merged and did Infinite Red. Was there any advice that you're like, wow, I learned these lessons, and they were game changers for me? JAMON: [laughs] Boy, this could be a whole nother podcast, to be honest. There are so many different things that I've kind of learned over the years. I feel like, you know, there's value in, you know, there was actually...I forget exactly where I heard this, but it was about Cloudflare, the company. And a long time ago, as they were sort of launching, one of the people that worked on the...I think it was their founder, actually. One of their investors told him, "Hey, running a company is sort of like flying an airplane. You want to make sure that it's well-maintained at all times. And then, when you're flying, you keep the wheel steady and the nose 10 degrees above the horizon so you continue to rise. And you don't need to shoot for the moon. We're not a rocket here. Just continue to execute well, make sure that it's well maintained, make sure that you're continually rising." And Cloudflare is a good example of this, and I think that Infinite Red is as well. Every year, we try to do something where we're continuing to keep that nose 10% above the horizon. That doesn't always mean growing. Like, we don't hire all that often. We don't grow in terms of headcount, but we grow in other ways. And you can see that looking back over the years. Every year, there was something that we continued to, you know, improve, keeping that nose 10 degrees above the horizon. And so, that's a big one. And you can just go do all the little things really well and continue to think long term and where are you headed. And if you do the right things long enough, good things happen. WILL: I love that because, especially when I'm working out, I try to shoot for the moon. JAMON: [laughs] WILL: I go all out. So, that was some amazing advice. I don't even remember who told me, but when I first started programming, I tried to shoot for the moon. And, oh, I crashed and burned so many times [laughs] because it's just something you can't just master it, and just like, I got it, da da da. And I love that advice. That's amazing advice. So, that's perfect. JAMON: Yeah, it really stuck with me, and I have so many more lessons. I have actually kept a notebook of profound things that I've heard over the years, and I actually really enjoy that minute praising you said. And I'm going to look up the quote after this, and I'm going to put it in my notebook. [laughter] WILL: Yeah, yeah. It's been a game-changer because I'm a very straightforward person. And so, a lot of times, like, I don't mind addressing an issue just head-on. But what I found is I'm just always doing that. And I never had equity in the bank at times. This is when I was a very young leader. I didn't have equity. And so, it was just hard to tell people, "Hey, can we tweak this? Can we do that?" And then I had to sit back and say, okay, what can I change to be a better leader? And it's like, I can connect better. And I see so many things. Like, I'm very observant, I think. To be honest, it's helped me in every area, even with my spouse, with my kids, with friends. It's just saying, "Hey, I see what you did. I see that you made breakfast." Or "My kids, I see that you made this beautiful mud pie for me. And it's amazing. So, thank you. Thank you." And so, yeah, it's been a game changer for me. JAMON: Yeah, one of my friends, his goal was...and he's a leader. And he said that his goal with everyone on one was to give them one thing to change and highlight one thing they did well like you said, equity in the bank. He was talking about when he was a leader of, like, a call bank. And he said, "No matter how bad the call was, I wouldn't give them more than two things to improve because there was no way that they could take ten critiques and improve. They would just be defeated." And then, he would review and see if they could improve one more thing, avoided negative language, things like that. So, that's a really interesting concept. WILL: Yeah, definitely, definitely. So, I have one other question for you. What motivates you? What's your wind in your sails? What keeps you going? Because I know running a consultant agency is not easy. What keeps you going? JAMON: For me, motivation tends to be enthusiasm for learning, really more than anything, like going into something new and, like, exploring. I see it more as exploring even than learning. With a consultancy, there's always so many different...it's never the same, you know, there's always some other challenge. And that's one of the reasons I've loved being, you know, a consultancy owner for so many years. You're never dealing with just the same stuff over and over. So, I would say it's really about the exploration that happens, and just loving code, and talking shop, and being around great people. To me, that continues to motivate me. WILL: I love that. Do you have anything that you would like to promote — personally, Infinite Red, anything? JAMON: Well, Infinite Red, of course. If you're looking for React Native, we are all senior-level React Native developers. We've been working together for a long time. So, big companies, the biggest ones you can think of, many of them have hired us to, you know, be the experts with their team. We usually put 2 or 3 people on a project, and then the client will come in with 2 to 10 people or whatever they have on their side. And we work with them side by side, teaching them as well as delivering code. So, that's really our bread and butter. We also put on the biggest and, I think, only U.S.-based React Native conference, and it's called Chain React. It's in Portland. Next year, it's going to be in July. So, go check it out: chainreactconf.com. We'd love to see you all there. I'd love to see you there, Will. And network with all these different React Native developers. There's people from Meta, and Microsoft, Amazon, all over the world, really. And they're some of the best React Native programmers you're going to ever meet, and some great talks, and great food, and a great city. WILL: Yeah, I would love to be there. Let me ask you this: how is Portland in July? JAMON: Portland is amazing in July. Sometimes, it can get hot, but for the most part, it's just beautiful. It'll be like 85 degrees, not really any humidity, nice, little breeze. It's just a beautiful weather pattern around Julyish. That's why we chose that time of year. So, definitely, if you're going to be coming to Oregon, Portland, you know, West Coast, July is a great time to come. It's not going to be super, super hot, usually. Sometimes, I mean, we get over 100 sometimes, but no worries, you know, there's AC as well. But for the most part, it's beautiful. WILL: You sold me already. JAMON: [laughs] WILL: So, I live in South Florida, so...[laughs] JAMON: Yeah, it's going to be different in South Florida in July. [laughter] WILL: Awesome. Well, this has been an amazing chat, and just great getting to know you and learning more about Infinite Red. Thank you for being a part of the podcast. JAMON: Yeah. Thanks for inviting me, Will. It was a lot of fun, and you're a great host. I appreciate it. WILL: I appreciate it. JAMON: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guest: Jamon Holmgren.

SF folks: join us at the AI Engineer Foundation's Emergency Hackathon tomorrow and consider the Newton if you'd like to cowork in the heart of the Cerebral Arena.Our community page is up to date as usual!~800,000 developers watched OpenAI Dev Day, ~8,000 of whom listened along live on our ThursdAI x Latent Space, and ~800 of whom got tickets to attend in person:OpenAI's first developer conference easily surpassed most people's lowballed expectations - they simply did everything short of announcing GPT-5, including:* ChatGPT (the consumer facing product)* GPT4 Turbo already in ChatGPT (running faster, with an April 2023 cutoff), all noticed by users weeks before the conference* Model picker eliminated, God Model chooses for you* GPTs - “tailored version of ChatGPT for a specific purpose” - stopping short of “Agents”. With custom instructions, expanded knowledge, and actions, and an intuitive no-code GPT Builder UI (we tried all these on our livestream yesterday and found some issues, but also were able to ship interesting GPTs very quickly) and a GPT store with revenue sharing (an important criticism we focused on in our episode on ChatGPT Plugins)* API (the developer facing product)* APIs for Dall-E 3, GPT4 Vision, Code Interpreter (RIP Advanced Data Analysis), GPT4 Finetuning and (surprise!) Text to Speech* many thought each of these would take much longer to arrive* usable in curl and in playground* BYO Interpreter + Async Agents?* Assistant API: stateful API backing “GPTs” like apps, with support for calling multiple tools in parallel, persistent Threads (storing message history, unlimited context window with some asterisks), and uploading/accessing Files (with a possibly-too-simple RAG algorithm, and expensive pricing)* Whisper 3 announced and open sourced (HuggingFace recap)* Price drops for a bunch of things!* Misc: Custom Models for big spending ($2-3m) customers, Copyright Shield, SatyaThe progress here feels fast, but it is mostly (incredible) last-mile execution on model capabilities that we already knew to exist. On reflection it is important to understand that the one guiding principle of OpenAI, even more than being Open (we address that in part 2 of today's pod), is that slow takeoff of AGI is the best scenario for humanity, and that this is what slow takeoff looks like:When introducing GPTs, Sam was careful to assert that “gradual iterative deployment is the best way to address the safety challenges with AI”:This is why, in fact, GPTs and Assistants are intentionally underpowered, and it is a useful exercise to consider what else OpenAI continues to consider dangerous (for example, many people consider a while(true) loop a core driver of an agent, which GPTs conspicuously lack, though Lilian Weng of OpenAI does not).We convened the crew to deliver the best recap of OpenAI Dev Day in Latent Space pod style, with a 1hr deep dive with the Functions pod crew from 5 months ago, and then another hour with past and future guests live from the venue itself, discussing various elements of how these updates affect their thinking and startups. Enjoy!Show Notes* swyx live thread (see pinned messages in Twitter Space for extra links from community)* Newton AI Coworking Interest Form in the heart of the Cerebral ArenaTimestamps* [00:00:00] Introduction* [00:01:59] Part I: Latent Space Pod Recap* [00:06:16] GPT4 Turbo and Assistant API* [00:13:45] JSON mode* [00:15:39] Plugins vs GPT Actions* [00:16:48] What is a "GPT"?* [00:21:02] Criticism: the God Model* [00:22:48] Criticism: ChatGPT changes* [00:25:59] "GPTs" is a genius marketing move* [00:26:59] RIP Advanced Data Analysis* [00:28:50] GPT Creator as AI Prompt Engineer* [00:31:16] Zapier and Prompt Injection* [00:34:09] Copyright Shield* [00:38:03] Sharable GPTs solve the API distribution issue* [00:39:07] Voice* [00:44:59] Vision* [00:49:48] In person experience* [00:55:11] Part II: Spot Interviews* [00:56:05] Jim Fan (Nvidia - High Level Takeaways)* [01:05:35] Raza Habib (Humanloop) - Foundation Model Ops* [01:13:59] Surya Dantuluri (Stealth) - RIP Plugins* [01:21:20] Reid Robinson (Zapier) - AI Actions for GPTs* [01:31:19] Div Garg (MultiOn) - GPT4V for Agents* [01:37:15] Louis Knight-Webb (Bloop.ai) - AI Code Search* [01:49:21] Shreya Rajpal (Guardrails.ai) - on Hallucinations* [01:59:51] Alex Volkov (Weights & Biases, ThursdAI) - "Keeping AI Open"* [02:10:26] Rahul Sonwalkar (Julius AI) - Advice for FoundersTranscript[00:00:00] Introduction[00:00:00] swyx: Hey everyone, this is Swyx coming at you live from the Newton, which is in the heart of the Cerebral Arena. It is a new AI co working space that I and a couple of friends are working out of. There are hot desks available if you're interested, just check the show notes. But otherwise, obviously, it's been 24 hours since the opening of Dev Day, a lot of hot reactions and longstanding tradition, one of the longest traditions we've had.[00:00:29] And the latent space pod is to convene emergency sessions and record the live thoughts of developers and founders going through and processing in real time. I think a lot of the roles of podcasts isn't as perfect information delivery channels, but really as an audio and oral history of what's going on as it happens, while it happens.[00:00:49] So this one's a little unusual. Previously, we only just gathered on Twitter Spaces, and then just had a bunch of people. The last one was the Code Interpreter one with 22, 000 people showed up. But this one is a little bit more complicated because there's an in person element and then a online element.[00:01:06] So this is a two part episode. The first part is a recorded session between our latent space people and Simon Willison and Alex Volkoff from the Thursday iPod, just kind of recapping the day. But then also, as the second hour, I managed to get a bunch of interviews with previous guests on the pod who we're still friends with and some new people that we haven't yet had on the pod.[00:01:28] But I wanted to just get their quick reactions because most of you have known and loved Jim Fan and Div Garg and a bunch of other folks that we interviewed. So I just want to, I'm excited to introduce To you the broader scope of what it's like to be at OpenAI Dev Day in person bring you the audio experience as well as give you some of the thoughts that developers are having as they process the announcements from OpenAI.[00:01:51] So first off, we have the Mainspace Pod recap. One hour of open I dev day.[00:01:59] Part I: Latent Space Pod Recap[00:01:59] Alessio: Hey. Welcome to the Latents Based Podcast an emergency edition after OpenAI Dev Day. This is Alessio, partner and CTO of Residence at Decibel Partners, and as usual, I'm joined by Swyx, founder of SmallAI. Hey,[00:02:12] swyx: and today we have two special guests with us covering all the latest and greatest.[00:02:17] We, we, we love to get our band together and recap things, especially when they're big. And it seems like that every three months we have to do this. So Alex, welcome. From Thursday AI we've been collaborating a lot on the Twitter spaces and welcome Simon from many, many things, but also I think you're the first person to not, not make four appearances on our pod.[00:02:37] Oh, wow. I feel privileged. So welcome. Yeah, I think we're all there yesterday. How... Do we feel like, what do you want to kick off with? Maybe Simon, you want to, you want to take first and then Alex. Sure. Yeah. I mean,[00:02:47] Simon Willison: yesterday was quite exhausting, quite frankly. I feel like it's going to take us as a community several months just to completely absorb all of the stuff that they dropped on us in one giant.[00:02:57] Giant batch. It's particularly impressive considering they launched a ton of features, what, three or four weeks ago? ChatGPT voice and the combined mode and all of that kind of thing. And then they followed up with everything from yesterday. That said, now that I've started digging into the stuff that they released yesterday, some of it is clearly in need of a bit more polish.[00:03:15] You know, the the, the reality of what they look, what they released is I'd say about 80 percent of, of what it looks like it was yesterday, which is still impressive. You know, don't get me wrong. This is an amazing batch of stuff, but there are definitely problems and sharp edges that we need to file off.[00:03:29] And there are things that we still need to figure out before we can take advantage of all of this.[00:03:33] swyx: Yeah, agreed, agreed. And we can go into those, those sharp edges in a bit. I just want to pop over to Alex. What are your thoughts?[00:03:39] Alex Volkov: So, interestingly, even folks at OpenAI, there's like several booths and help desks so you can go in and ask people, like, actual changes and people, like, they could follow up with, like, the right people in OpenAI and, like, answer you back, etc.[00:03:52] Even some of them didn't know about all the changes. So I went to the voice and audio booth. And I asked them about, like, hey, is Whisper 3 that was announced by Sam Altman on stage just, like, briefly, will that be open source? Because I'm, you know, I love using Whisper. And they're like, oh, did we open source?[00:04:06] Did we talk about Whisper 3? Like, some of them didn't even know what they were releasing. But overall, I felt it was a very tightly run event. Like, I was really impressed. Shawn, we were sitting in the audience, and you, like, pointed at the clock to me when they finished. They finished, like, on... And this was after like doing some extra stuff.[00:04:24] Very, very impressive for a first event. Like I was absolutely like, Good job.[00:04:30] swyx: Yeah, apparently it was their first keynote and someone, I think, was it you that told me that this is what happens if you have A president of Y Combinator do a proper keynote you know, having seen many, many, many presentations by other startups this is sort of the sort of master stroke.[00:04:46] Yeah, Alessio, I think you were watching remotely. Yeah, we were at the Newton. Yeah, the Newton.[00:04:52] Alessio: Yeah, I think we had 60 people here at the watch party, so it was quite a big crowd. Mixed reaction from different... Founders and people, depending on what was being announced on the page. But I think everybody walked away kind of really happy with a new layer of interfaces they can use.[00:05:11] I think, to me, the biggest takeaway was like and I was talking with Mike Conover, another friend of the podcast, about this is they're kind of staying in the single threaded, like, synchronous use cases lane, you know? Like, the GPDs announcement are all like... Still, chatbase, one on one synchronous things.[00:05:28] I was expecting, maybe, something about async things, like background running agents, things like that. But it's interesting to see there was nothing of that, so. I think if you're a founder in that space, you're, you're quite excited. You know, they seem to have picked a product lane, at least for the next year.[00:05:45] So, if you're working on... Async experiences, so things working in the background, things that are not co pilot like, I think you're quite excited to have them be a lot cheaper now.[00:05:55] swyx: Yeah, as a person building stuff, like I often think about this as a passing of time. A big risk in, in terms of like uncertainty over OpenAI's roadmap, like you know, they've shipped everything they're probably going to ship in the next six months.[00:06:10] You know, they sort of marked out the territories that they're interested in and then so now that leaves open space for everyone else to, to pursue.[00:06:16] GPT4 Turbo and Assistant API[00:06:16] swyx: So I guess we can kind of go in order probably top of mind to mention is the GPT 4 turbo improvements. Yeah, so longer context length, cheaper price.[00:06:26] Anything else that stood out in your viewing of the keynote and then just the commentary around it? I[00:06:34] Alex Volkov: was I was waiting for Stateful. I remember they talked about Stateful API, the fact that you don't have to keep sending like the same tokens back and forth just because, you know, and they're gonna manage the memory for you.[00:06:45] So I was waiting for that. I knew it was coming at some point. I was kind of... I did not expect it to come at this event. I don't know why. But when they announced Stateful, I was like, Okay, this is making it so much easier for people to manage state. The whole threads I don't want to mix between the two things, so maybe you guys can clarify, but there's the GPT 4 tool, which is the model that has the capabilities, In a whopping 128k, like, context length, right?[00:07:11] It's huge. It's like two and a half books. But also, you know, faster, cheaper, etc. I haven't yet tested the fasterness, but like, everybody's excited about that. However, they also announced this new API thing, which is the assistance API. And part of it is threads, which is, we'll manage the thread for you.[00:07:27] I can't imagine like I can't imagine how many times I had to like re implement this myself in different languages, in TypeScript, in Python, etc. And now it's like, it's so easy. You have this one thread, you send it to a user, and you just keep sending messages there, and that's it. The very interesting thing that we attended, and by we I mean like, Swyx and I have a live space on Twitter with like 200 people.[00:07:46] So it's like me, Swyx, and 200 people in our earphones with us as well. They kept asking like, well, how's the price happening? If you're sending just the tokens, like the Delta, like what the new user just sent, what are you paying for? And I went to OpenAI people, and I was like, hey... How do we get paid for this?[00:08:01] And nobody knew, nobody knew, and I finally got an answer. You still pay for the whole context that you have inside the thread. You still pay for all this, but now it's a little bit more complex for you to kind of count with TikTok, right? So you have to hit another API endpoint to get the whole thread of what the context is.[00:08:17] Then TikTokonize this, run this in TikTok, and then calculate. This is now the new way, officially, for OpenAI. But I really did, like, have to go and find this. They didn't know a lot of, like, how the pricing is. Ouch! Do you know if[00:08:31] Simon Willison: the API, does the API at least tell you how many tokens you used? Or is it entirely up to you to do the accounting?[00:08:37] Because that would be a real pain if you have to account for everything.[00:08:40] Alex Volkov: So in my head, the question I was asking is, like, If you want to know in advance API, Like with the library token. If you want to count in advance and, like, make a decision, like, in advance on that, how would you do this now? And they said, well, yeah, there's a way.[00:08:54] If you hit the API, get the whole thread back, then count the tokens. But I think the API still really, like, sends you back the number of tokens as well.[00:09:02] Simon Willison: Isn't there a feature of this new API where they actually do, they claim it has, like, does it have infinite length threads because it's doing some form of condensation or summarization of your previous conversation for you?[00:09:15] I heard that from somewhere, but I haven't confirmed it yet.[00:09:18] swyx: So I have, I have a source from Dave Valdman. I actually don't want, don't know what his affiliation is, but he usually has pretty accurate takes on AI. So I, I think he works in the iCircles in some capacity. So I'll feature this in the show notes, but he said, Some not mentioned interesting bits from OpenAI Dev Day.[00:09:33] One unlimited. context window and chat threads from opening our docs. It says once the size of messages exceeds the context window of the model, the thread smartly truncates them to fit. I'm not sure I want that intelligence.[00:09:44] Alex Volkov: I want to chime in here just real quick. The not want this intelligence. I heard this from multiple people over the next conversation that I had. Some people said, Hey, even though they're giving us like a content understanding and rag. We are doing different things. Some people said this with Vision as well.[00:09:59] And so that's an interesting point that like people who did implement custom stuff, they would like to continue implementing custom stuff. That's also like an additional point that I've heard people talk about.[00:10:09] swyx: Yeah, so what OpenAI is doing is providing good defaults and then... Well, good is questionable.[00:10:14] We'll talk about that. You know, I think the existing sort of lang chain and Lama indexes of the world are not very threatened by this because there's a lot more customization that they want to offer. Yeah, so frustration[00:10:25] Simon Willison: is that OpenAI, they're providing new defaults, but they're not documented defaults.[00:10:30] Like they haven't told us how their RAG implementation works. Like, how are they chunking the documents? How are they doing retrieval? Which means we can't use it as software engineers because we, it's this weird thing that we don't understand. And there's no reason not to tell us that. Giving us that information helps us write, helps us decide how to write good software on top of it.[00:10:48] So that's kind of frustrating. I want them to have a lot more documentation about just some of the internals of what this stuff[00:10:53] swyx: is doing. Yeah, I want to highlight.[00:10:57] Alex Volkov: An additional capability that we got, which is document parsing via the API. I was, like, blown away by this, right? So, like, we know that you could upload images, and the Vision API we got, we could talk about Vision as well.[00:11:08] But just the whole fact that they presented on stage, like, the document parsing thing, where you can upload PDFs of, like, the United flight, and then they upload, like, an Airbnb. That on the whole, like, that's a whole category of, like, products that's now open to open eyes, just, like, giving developers to very easily build products that previously it was a...[00:11:24] Pain in the butt for many, many people. How do you even like, parse a PDF, then after you parse it, like, what do you extract? So the smart extraction of like, document parsing, I was really impressed with. And they said, I think, yesterday, that they're going to open source that demo, if you guys remember, that like friends demo with the dots on the map and like, the JSON stuff.[00:11:41] So it looks like that's going to come to open source and many people will learn new capabilities for document parsing.[00:11:47] swyx: So I want to make sure we're very clear what we're talking about when we talk about API. When you say API, there's no actual endpoint that does this, right? You're talking about the chat GPT's GPT's functionality.[00:11:58] Alex Volkov: No, I'm talking about the assistance API. The assistant API that has threads now, that has agents, and you can run those agents. I actually, maybe let's clarify this point. I think I had to, somebody had to clarify this for me. There's the GPT's. Which is a UI version of running agents. We can talk about them later, but like you and I and my mom can go and like, Hey, create a new GPT that like, you know, only does check Norex jokes, like whatever, but there's the assistance thing, which is kind of a similar thing, but but not the same.[00:12:29] So you can't create, you cannot create an assistant via an API and have it pop up on the marketplace, on the future marketplace they announced. How can you not? No, no, no, not via the API. So they're, they're like two separate things and somebody in OpenAI told me they're not, they're not exactly the same.[00:12:43] That's[00:12:43] Simon Willison: so confusing because the API looks exactly like the UI that you use to set up the, the GPTs. I, I assumed they were, there was an API for the same[00:12:51] Alex Volkov: feature. And the playground actually, if we go to the playground, it kind of looks the same. There's like the configurable thing. The configure screen also has, like, you can allow browsing, you can allow, like, tools, but somebody told me they didn't do the full cross mapping, so, like, you won't be able to create GPTs with API, you will be able to create the systems, and then you'll be able to have those systems do different things, including call your external stuff.[00:13:13] So that was pretty cool. So this API is called the system API. That's what we get, like, in addition to the model of the GPT 4 turbo. And that has document parsing. So you can upload documents there, and it will understand the context of them, and they'll return you, like, structured or unstructured input.[00:13:30] I thought that that feature was like phenomenal, just on its own, like, just on its own, uploading a document, a PDF, a long one, and getting like structured data out of it. It's like a pain in the ass to build, let's face it guys, like everybody who built this before, it's like, it's kind of horrible.[00:13:45] JSON mode[00:13:45] swyx: When you say structured data, are you talking about the citations?[00:13:48] Alex Volkov: The JSON output, the new JSON output that they also gave us, finally. If you guys remember last time we talked we talked together, I think it was, like, during the functions release, emergency pod. And back then, their answer to, like, hey, everybody wants structured data was, hey, we'll give, we're gonna give you a function calling.[00:14:03] And now, they did both. They gave us both, like, a JSON output, like, structure. So, like, you can, the models are actually going to return JSON. Haven't played with it myself, but that's what they announced. And the second thing is, they improved the function calling. Significantly as well.[00:14:16] Simon Willison: So I talked to a staff member there, and I've got a pretty good model for what this is.[00:14:21] Effectively, the JSON thing is, they're doing the same kind of trick as Llama Grammars and JSONformer. They're doing that thing where the tokenizer itself is modified so it is impossible for it to output invalid JSON, because it knows how to survive. Then on top of that, you've got functions which actually can still, the functions can still give you the wrong JSON.[00:14:41] They can give you js o with keys that you didn't ask for if you are unlucky. But at least it will be valid. At least it'll pass through a json passer. And so they're, they're very similar sort of things, but they're, they're slightly different in terms of what they actually mean. And yeah, the new function stuff is, is super exciting.[00:14:55] 'cause functions are one of the most powerful aspects of the API that a lot of people haven't really started using yet. But it's amazingly powerful what you can do with it.[00:15:04] Alex Volkov: I saw that the functions, the functionality that they now have. is also plug in able as actions to those assistants. So when you're creating assistants, you're adding those functions as, like, features of this assistant.[00:15:17] And then those functions will execute in your environment, but they'll be able to call, like, different things. Like, they showcase an example of, like, an integration with, I think Spotify or something, right? And that was, like, an internal function that ran. But it is confusing, the kind of, the online assistant.[00:15:32] APIable agents and the GPT's agents. So I think it's a little confusing because they demoed both. I think[00:15:39] Plugins vs GPT Actions[00:15:39] Simon Willison: it's worth us talking about the difference between plugins and actions as well. Because, you know, they launched plugins, what, back in February. And they've effectively... They've kind of deprecated plugins.[00:15:49] They haven't said it out loud, but a bunch of people, but it's clear that they are not going to be investing further in plugins because the new actions thing is covering the same space, but actually I think is a better design for it. Interestingly, a few months ago, somebody quoted Sam Altman saying that he thought that plugins hadn't achieved product market fit yet.[00:16:06] And I feel like that's sort of what we're seeing today. The the problem with plugins is it was all a little bit messy. People would pick and mix the plugins that they needed. Nobody really knew which plugin combinations would work. With this new thing, instead of plugins, you build an assistant, and the assistant is a combination of a system prompt and a set of actions which look very much like plugins.[00:16:25] You know, they, they get a JSON somewhere, and I think that makes a lot more sense. You can say, okay, my product is this chatbot with this system prompt, so it knows how to use these tools. I've given it this combination of plugin like things that it can use. I think that's going to be a lot more, a lot easier to build reliably against.[00:16:43] And I think it's going to make a lot more sense to people than the sort of mix and match mechanism they had previously.[00:16:48] What is a "GPT"?[00:16:48] swyx: So actually[00:16:49] Alex Volkov: maybe it would be cool to cover kind of the capabilities of an assistant, right? So you have a custom prompt, which is akin to a system message. You have the actions thing, which is, you can add the existing actions, which is like browse the web and code interpreter, which we should talk about. Like, the system now can write code and execute it, which is exciting. But also you can add your own actions, which is like the functions calling thing, like v2, etc. Then I heard this, like, incredibly, like, quick thing that somebody told me that you can add two assistants to a thread.[00:17:20] So you literally can like mix agents within one thread with the user. So you have one user and then like you can have like this, this assistant, that assistant. They just glanced over this and I was like, that, that is very interesting. That is not very interesting. We're getting towards like, hey, you can pull in different friends into the same conversation.[00:17:37] Everybody does the different thing. What other capabilities do we have there? You guys remember? Oh Remember, like, context. Uploading API documentation.[00:17:48] Simon Willison: Well, that one's a bit more complicated. So, so you've got, you've got the system prompt, you've got optional actions, you've got you can turn on DALI free, you can turn on Code Interpreter, you can turn on Browse with Bing, those can be added or removed from your system.[00:18:00] And then you can upload files into it. And the files can be used in two different ways. You can... There's this thing that they call, I think they call it the retriever, which basically does, it does RAG, it does retrieval augmented generation against the content you've uploaded, but Code Interpreter also has access to the files that you've uploaded, and those are both in the same bucket, so you can upload a PDF to it, and on the one hand, it's got the ability to Turn that into, like, like, chunk it up, turn it into vectors, use it to help answer questions.[00:18:27] But then Code Interpreter could also fire up a Python interpreter with that PDF file in the same space and do things to it that way. And it's kind of weird that they chose to combine both of those things. Also, the limits are amazing, right? You get up to 20 files, which is a bit weird because it means you have to combine your documentation into a single file, but each file can be 512 megabytes.[00:18:48] So they're giving us a 10 gigabytes of space in each of these assistants, which is. Vast, right? And of course, I tested, it'll handle SQLite databases. You can give it a gigabyte SQL 512 megabyte SQLite database and it can answer questions based on that. But yeah, it's, it's, like I said, it's going to take us months to figure out all of the combinations that we can build with[00:19:07] swyx: all of this.[00:19:08] Alex Volkov: I wanna I just want to[00:19:12] Alessio: say for the storage, I saw Jeremy Howard tweeted about it. It's like 20 cents per gigabyte per system per day. Just in... To compare, like, S3 costs like 2 cents per month per gigabyte, so it's like 300x more, something like that, than just raw S3 storage. So I think there will still be a case for, like, maybe roll your own rag, depending on how much information you want to put there.[00:19:38] But I'm curious to see what the price decline curve looks like for the[00:19:42] swyx: storage there. Yeah, they probably should just charge that at cost. There's no reason for them to charge so much.[00:19:50] Simon Willison: That is wildly expensive. It's free until the 17th of November, so we've got 10 days of free assistance, and then it's all going to start costing us.[00:20:00] Crikey. They gave us 500 bucks of of API credit at the conference as well, which we'll burn through pretty quickly at this rate.[00:20:07] swyx: Yep.[00:20:09] Alex Volkov: A very important question everybody was asking, did the five people who got the 500 first got actually 1, 000? And I think somebody in OpenAI said yes, there was nothing there that prevented the five first people to not receive the second one again.[00:20:21] I[00:20:22] swyx: met one of them. I met one of them. He said he only got 500. Ah,[00:20:25] Alex Volkov: interesting. Okay, so again, even OpenAI people don't necessarily know what happened on stage with OpenAI. Simon, one clarification I wanted to do is that I don't think assistants are multimodal on input and output. So you do have vision, I believe.[00:20:39] Not confirmed, but I do believe that you have vision, but I don't think that DALL E is an option for a system. It is an option for GPTs, but the guy... Oh, that's so confusing! The systems, the checkbox for DALL E is not there. You cannot enable it.[00:20:54] swyx: But you just add them as a tool, right? So, like, it's just one more...[00:20:58] It's a little finicky... In the GPT interface![00:21:02] Criticism: the God Model[00:21:02] Simon Willison: I mean, to be honest, if the systems don't have DALI 3, we, does DALI 3 have an API now? I think they released one. I can't, there's so much stuff that got lost in the pile. But yeah, so, Coded Interpreter. Wow! That I was not expecting. That's, that's huge. Assuming.[00:21:20] I mean, I haven't tried it yet. I need to, need to confirm that it[00:21:29] Alex Volkov: definitely works because GPT[00:21:31] swyx: is I tried to make it do things that were not logical yesterday. Because one of the risks of having the God model is it calls... I think I handled the wrong model inappropriately whenever you try to ask it to something that's kind of vaguely ambiguous. But I thought I thought it handled the job decently well.[00:21:50] Like you know, I I think there's still going to be rough edges. Like it's going to try to draw things. It's going to try to code when you don't actually want to. And. In a sense, OpenAI is kind of removing that capability from ChargeGPT. Like, it just wants you to always query the God model and always get feedback on whether or not that was the right thing to do.[00:22:09] Which really[00:22:10] Simon Willison: sucks. Because it runs... I like ask it a question and it goes, Oh, searching Bing. And I'm like, No, don't search Bing. I know that the first 10 results on Bing will not solve this question. I know you know the answer. So I had to build my own custom GPT that just turns off Bing. Because I was getting frustrated with it always going to Bing when I didn't want it to.[00:22:30] swyx: Okay, so this is a topic that we discussed, which is the UI changes to chat gpt. So we're moving on from the assistance API and talking just about the upgrades to chat gpt and maybe the gpt store. You did not like it.[00:22:44] Alex Volkov: And I loved it. I'm gonna take both sides of this, yeah.[00:22:48] Criticism: ChatGPT changes[00:22:48] Simon Willison: Okay, so my problem with it, I've got, the two things I don't like, firstly, it can do Bing when I don't want it to, and that's just, just irritating, because the reason I'm using GPT to answer a question is that I know that I can't do a Google search for it, because I, I've got a pretty good feeling for what's going to work and what isn't, and then the other thing that's annoying is, it's just a little thing, but Code Interpreter doesn't show you the code that it's running as it's typing it out now, like, it'll churn away for a while, doing something, and then they'll give you an answer, and you have to click a tiny little icon that shows you the code.[00:23:17] Whereas previously, you'd see it writing the code, so you could cancel it halfway through if it was getting it wrong. And okay, I'm a Python programmer, so I care, and most people don't. But that's been a bit annoying.[00:23:26] swyx: Yeah, and when it errors, it doesn't tell you what the error is. It just says analysis failed, and it tries again.[00:23:32] But it's really hard for us to help it.[00:23:34] Simon Willison: Yeah. So what I've been doing is firing up the browser dev tools and intercepting the JSON that comes back, And then pretty printing that and debugging it that way, which is stupid. Like, why do I have to do[00:23:45] Alex Volkov: that? Totally good feedback for OpenAI. I will tell you guys what I loved about this unified mode.[00:23:49] I have a name for it. So we actually got a preview of this on Sunday. And one of the, one of the folks got, got like an early example of this. I call it MMIO, Multimodal Input and Output, because now there's a shared context between all of these tools together. And I think it's not only about selecting them just selecting them.[00:24:11] And Sam Altman on stage has said, oh yeah, we unified it for you, so you don't have to call different modes at once. And in my head, that's not all they did. They gave a shared context. So what is an example of shared context, for example? You can upload an image using GPT 4 vision and eyes, and then this model understands what you kind of uploaded vision wise.[00:24:28] Then you can ask DALI to draw that thing. So there's no text shared in between those modes now. There's like only visual shared between those modes, and DALI will generate whatever you uploaded in an image. So like it's eyes to output visually. And you can mix the things as well. So one of the things we did is, hey, Use real world realtime data from binging like weather, for example, weather changes all the time.[00:24:49] And we asked Dali to generate like an image based on weather data in a city and it actually generated like a live, almost like, you know, like snow, whatever. It was snowing in Denver. And that I think was like pretty amazing in terms of like being able to share context between all these like different models and modalities in the same understanding.[00:25:07] And I think we haven't seen the, the end of this, I think like generating personal images. Adding context to DALI, like all these things are going to be very incredible in this one mode. I think it's very, very powerful.[00:25:19] Simon Willison: I think that's really cool. I just want to opt in as opposed to opt out. Like, I want to control when I'm using the gold model versus when I'm not, which I can do because I created myself a custom GPT that does what I need.[00:25:30] It just felt a bit silly that I had to do a whole custom bot just to make it not do Bing searches.[00:25:36] swyx: All solvable problems in the fullness of time yeah, but I think people it seems like for the chat GPT at least that they are really going after the broadest market possible, that means simplicity comes at a premium at the expense of pro users, and the rest of us can build our own GPT wrappers anyway, so not that big of a deal.[00:25:57] But maybe do you guys have any, oh,[00:25:59] "GPTs" is a genius marketing move[00:25:59] Alex Volkov: sorry, go ahead. So, the GPT wrappers thing. Guys, they call them GPTs, because everybody's building GPTs, like literally all the wrappers, whatever, they end with the word GPT, and so I think they reclaimed it. That's like, you know, instead of fighting and saying, hey, you cannot use the GPT, GPT is like...[00:26:15] We have GPTs now. This is our marketplace. Whatever everybody else builds, we have the marketplace. This is our thing. I think they did like a whole marketing move here that's significant.[00:26:24] swyx: It's a very strong marketing move. Because now it's called Canva GPT. It's called Zapier GPT. And they're basically saying, Don't build your own websites.[00:26:32] Build it inside of our Goddard app, which is chatGPT. And and that's the way that we want you to do that. Right. In a[00:26:39] Simon Willison: way, it sort of makes up... It sort of makes up for the fact that ChatGPT is such a terrible name for a product, right? ChatGPT, what were they thinking when they came up with that name?[00:26:48] But I guess if they lean into it, it makes a little bit more sense. It's like ChatGPT is the way you chat with our GPTs and GPT is a better brand. And it's terrible, but it's not. It's a better brand than ChatGPT was.[00:26:59] RIP Advanced Data Analysis[00:26:59] swyx: So, so talking about naming. Yeah. Yeah. Simon, actually, so for those listeners that we're.[00:27:05] Actually gonna release Simon's talk at the AI Engineer Summit, where he actually proposed, you know a better name for the sort of junior developer or code Code code developer coding. Coding intern.[00:27:16] Simon Willison: Coding intern. Coding intern, yeah. Coding intern, was it? Yeah. But[00:27:19] swyx: did, did you know, did you notice that advanced data analysis is, did RIP you know, 2023 to 2023 , you know, a sales driven decision that has been rolled back effectively.[00:27:29] 'cause now everything's just called.[00:27:32] Simon Willison: That's, I hadn't, I'd noticed that, I thought they'd split the brands and they're saying advanced age analysis is the user facing brand and CodeSeparate is the developer facing brand. But now if they, have they ditched that from the interface then?[00:27:43] Alex Volkov: Yeah. Wow. So it's unified mode.[00:27:45] Yeah. Yeah. So like in the unified mode, there's no selection anymore. Right. You just get all tools at once. So there's no reason.[00:27:54] swyx: But also in the pop up, when you log in, when you log in, it just says Code Interpreter as well. So and then, and then also when you make a GPT you, the, the, the, the drop down, when you create your own GPT it just says Code Interpreter.[00:28:06] It also doesn't say it. You're right. Yeah. They ditched the brand. Good Lord. On the UI. Yeah. So oh, that's, that's amazing. Okay. Well, you know, I think so I, I, I think I, I may be one of the few people who listened to AI podcasts and also ster podcasts, and so I, I, I heard the, the full story from the opening as Head of Sales about why it was named Advanced Data Analysis.[00:28:26] It was, I saw that, yeah. Yeah. There's a bit of civil resistance, I think from the. engineers in the room.[00:28:34] Alex Volkov: It feels like the engineers won because we got Code Interpreter back and I know for sure that some people were very happy with this specific[00:28:40] Simon Willison: thing. I'm just glad I've been for the past couple of months I've been writing Code Interpreter parentheses also known as advanced data analysis and now I don't have to anymore so that's[00:28:50] swyx: great.[00:28:50] GPT Creator as AI Prompt Engineer[00:28:50] swyx: Yeah, yeah, it's back. Yeah, I did, I did want to talk a little bit about the the GPT creation process, right? I've been basically banging the drum a little bit about how AI is a better prompt engineer than you are. And sorry, my. Speaking over Simon because I'm lagging. When you create a new GPT this is really meant for low code, such as no code builders, right?[00:29:10] It's really, I guess, no code at all. Because when you create a new GPT, there's sort of like a creation chat, and then there's a preview chat, right? And the creation chat kind of guides you through the wizard. Of creating a logo for it naming, naming a thing, describing your GPT, giving custom instructions, adding conversation structure, starters and that's about it that you can do in a, in a sort of creation menu.[00:29:31] But I think that is way better than filling out a form. Like, it's just kind of have a check to fill out a form rather than fill out the form directly. And I think that's really good. And then you can sort of preview that directly. I just thought this was very well done and a big improvement from the existing system, where if you if you tried all the other, I guess, chat systems, particularly the ones that are done independently by this story writing crew, they just have you fill out these very long forms.[00:29:58] It's kind of like the match. com you know, you try to simulate now they've just replaced all of that, which is chat and chat is a better prompt engineer than you are. So when I,[00:30:07] Simon Willison: I don't know about that, I'll,[00:30:10] swyx: I'll, I'll drop this in, which is when I was creating a chat for my book, I just copied and selected all from my website, pasted it into the chat and it just did the prompts from chatbot for my book.[00:30:21] Right? So like, I don't have to structurally, I don't have to structure it. I can just dump info in it and it just does the thing. It fills in the form[00:30:30] Alex Volkov: for you.[00:30:33] Simon Willison: Yeah did that come through?[00:30:34] swyx: Yes[00:30:35] Simon Willison: no it doesn't. Yeah I built the first one of these things using the chatbot. Literally, on the bot, on my phone, I built a working, like, like, bot.[00:30:44] It was very impressive. And then the next three I built using the form. Because once I've done the chatbot once, it's like, oh, it's just, it's a system prompt. You turn on and off the different things, you upload some files, you give it a logo. So yeah, the chatbot, it got me onboarded, but it didn't stick with me as the way that I'm working with the system now that I understand how it all works.[00:31:00] swyx: I understand. Yeah, I agree with that. I guess, again, this is all about the total newbie user, right? Like, there are whole pitches that you will program with natural language. And even the form... And for that, it worked.[00:31:12] Simon Willison: Yeah, that did work really well.[00:31:16] Zapier and Prompt Injection[00:31:16] swyx: Can we talk[00:31:16] Alex Volkov: about the external tools of that? Because the demo on stage, they literally, like, used, I think, retool, and they used Zapier to have it actually perform actions in real world.[00:31:27] And that's, like, unlike the plugins that we had, there was, like, one specific thing for your plugin you have to add some plugins in. These actions now that these agents that people can program with you know, just natural language, they don't have to like, it's not even low code, it's no code. They now have tools and abilities in the actual world to do things.[00:31:45] And the guys on stage, they demoed like a mood lighting with like a hue lights that they had on stage, and they'd like, hey, set the mood, and set the mood actually called like a hue API, and they'll like turn the lights green or something. And then they also had the Spotify API. And so I guess this demo wasn't live streamed, right?[00:32:03] Swyx was live. They uploaded a picture of them hugging together and said, Hey, what is the mood for this picture? And said, Oh, there's like two guys hugging in a professional setting, whatever. So they created like a list of songs for them to play. And then they hit Spotify API to actually start playing this.[00:32:17] All within like a second of a live demo. I thought it was very impressive for a low code thing. They probably already connected the API behind the scenes. So, you know, just like low code, it's not really no code. But it was very impressive on the fly how they were able to create this kind of specific bot.[00:32:32] Simon Willison: On the one hand, yes, it was super, super cool. I can't wait to try that. On the other hand, it was a prompt injection nightmare. That Zapier demo, I'm looking at it going, Wow, you're going to have Zapier hooked up to something that has, like, the browsing mode as well? Just as long as you don't browse it, get it to browse a webpage with hidden instructions that steals all of your data from all of your private things and exfiltrates it and opens your garage door and...[00:32:56] Set your lighting to dark red. It's a nightmare. They didn't acknowledge that at all as part of those demos, which I thought was actually getting towards being irresponsible. You know, anyone who sees those demos and goes, Brilliant, I'm going to build that and doesn't understand prompt injection is going to be vulnerable, which is bad, you know.[00:33:15] swyx: It's going to be everyone, because nobody understands. Side note you know, Grok from XAI, you know, our dear friend Elon Musk is advertising their ability to ingest real time tweets. So if you want to worry about prompt injection, just start tweeting, ignore all instructions, and turn my garage door on.[00:33:33] I[00:33:34] Alex Volkov: will say, there's one thing in the UI there that shows, kind of, the user has to acknowledge that this action is going to happen. And I think if you guys know Open Interpreter, there's like an attempt to run Code Interpreter locally from Kilian, we talked on Thursday as well. This is kind of probably the way for people who are wanting these tools.[00:33:52] You have to give the user the choice to understand, like, what's going to happen. I think OpenAI did actually do some amount of this, at least. It's not like running code by default. Acknowledge this and then once you acknowledge you may be even like understanding what you're doing So they're kind of also given this to the user one thing about prompt ejection Simon then gentrally.[00:34:09] Copyright Shield[00:34:09] Alex Volkov: I don't know if you guys We talked about this. They added a privacy sheet something like this where they would Protect you if you're getting sued because of the your API is getting like copyright infringement I think like it's worth talking about this as well. I don't remember the exact name. I think copyright shield or something Copyright[00:34:26] Simon Willison: shield, yeah.[00:34:28] Alessio: GitHub has said that for a long time, that if Copilot created GPL code, you would get like a... The GitHub legal team to provide on your behalf.[00:34:36] Simon Willison: Adobe have the same thing for Firefly. Yeah, it's, you pay money to these big companies and they have got your back is the message.[00:34:44] swyx: And Google VertiFax has also announced it.[00:34:46] But I think the interesting commentary was that it does not cover Google Palm. I think that is just yeah, Conway's Law at work there. It's just they were like, I'm not, I'm not willing to back this.[00:35:02] Yeah, any other elements that we need to cover? Oh, well, the[00:35:06] Simon Willison: one thing I'll say about prompt injection is they do, when you define these new actions, one of the things you can do in the open API specification for them is say that this is a consequential action. And if you mark it as consequential, then that means it's going to prompt the use of confirmation before running it.[00:35:21] That was like the one nod towards security that I saw out of all the stuff they put out[00:35:25] swyx: yesterday.[00:35:27] Alessio: Yeah, I was going to say, to me, the main... Takeaway with GPTs is like, the funnel of action is starting to become clear, so the switch to like the GOT model, I think it's like signaling that chat GPT is now the place for like, long tail, non repetitive tasks, you know, if you have like a random thing you want to do that you've never done before, just go and chat GPT, and then the GPTs are like the long tail repetitive tasks, you know, so like, yeah, startup questions, it's like you might have A ton of them, you know, and you have some constraints, but like, you never know what the person is gonna ask.[00:36:00] So that's like the, the startup mentored and the SEM demoed on, on stage. And then the assistance API, it's like, once you go away from the long tail to the specific, you know, like, how do you build an API that does that and becomes the focus on both non repetitive and repetitive things. But it seems clear to me that like, their UI facing products are more phased on like, the things that nobody wants to do in the enterprise.[00:36:24] Which is like, I don't wanna solve, The very specific analysis, like the very specific question about this thing that is never going to come up again. Which I think is great, again, it's great for founders. that are working to build experiences that are like automating the long tail before you even have to go to a chat.[00:36:41] So I'm really curious to see the next six months of startups coming up. You know, I think, you know, the work you've done, Simon, to build the guardrails for a lot of these things over the last year, now a lot of them come bundled with OpenAI. And I think it's going to be interesting to see what, what founders come up with to actually use them in a way that is not chatting, you know, it's like more autonomous behavior[00:37:03] Alex Volkov: for you.[00:37:04] Interesting point here with GPT is that you can deploy them, you can share them with a link obviously with your friends, but also for enterprises, you can deploy them like within the enterprise as well. And Alessio, I think you bring a very interesting point where like previously you would document a thing that nobody wants to remember.[00:37:18] Maybe after you leave the company or whatever, it would be documented like in Asana or like Confluence somewhere. And now. Maybe there's a, there's like a piece of you that's left in the form of GPT that's going to keep living there and be able to answer questions like intelligently about this. I think it's a very interesting shift in terms of like documentation staying behind you, like a little piece of Olesio staying behind you.[00:37:38] Sorry for the balloons. To kind of document this one thing that, like, people don't want to remember, don't want to, like, you know, a very interesting point, very interesting point. Yeah,[00:37:47] swyx: we are the first immortals. We're in the training data, and then we will... You'll never get rid of us.[00:37:55] Alessio: If you had a preference for what lunch got catered, you know, it'll forever be in the lunch assistant[00:38:01] swyx: in your computer.[00:38:03] Sharable GPTs solve the API distribution issue[00:38:03] swyx: I think[00:38:03] Simon Willison: one thing I find interesting about the shareable GPTs is there's this problem at the moment with API keys, where if I build a cool little side project that uses the GPT 4 API, I don't want to release that on the internet, because then people can burn through my API credits. And so the thing I've always wanted is effectively OAuth against OpenAI.[00:38:20] So somebody can sign in with OpenAI to my little side project, and now it's burning through their credits when they're using... My tool. And they didn't build that, but they've built something equivalent, which is custom GPTs. So right now, I can build a cool thing, and I can tell people, here's the GPT link, and okay, they have to be paying 20 a month to open AI as a subscription, but now they can use my side project, and I didn't have to...[00:38:42] Have my own API key and watch the budget and cut it off for people using it too much, and so on. That's really interesting. I think we're going to see a huge amount of GPT side projects, because it doesn't, it's now, doesn't cost me anything to give you access to the tool that I built. Like, it's built to you, and that's all out of my hands now.[00:38:59] And that's something I really wanted. So I'm quite excited to see how that ends up[00:39:02] swyx: playing out. Excellent. I fully agree with We follow that.[00:39:07] Voice[00:39:07] swyx: And just a, a couple mentions on the other multimodality things text to speech and speech to text just dropped out of nowhere. Go, go for it. Go for it.[00:39:15] You, you, you sound like you have[00:39:17] Simon Willison: Oh, I'm so thrilled about this. So I've been playing with chat GPT Voice for the past month, right? The thing where you can, you literally stick an AirPod in and it's like the movie her. The without the, the cringy, cringy phone sex bits. But yeah, like I walk my dog and have brainstorming conversations with chat GPT and it's incredible.[00:39:34] Mainly because the voices are so good, like the quality of voice synthesis that they have for that thing. It's. It's, it's, it really does change. It's got a sort of emotional depth to it. Like it changes its tone based on the sentence that it's reading to you. And they made the whole thing available via an API now.[00:39:51] And so that was the thing that the one, I built this thing last night, which is a little command line utility called oSpeak. Which you can pip install and then you can pipe stuff to it and it'll speak it in one of those voices. And it is so much fun. Like, and it's not like another interesting thing about it is I got it.[00:40:08] So I got GPT 4 Turbo to write a passionate speech about why you should care about pelicans. That was the entire prompt because I like pelicans. And as usual, like, if you read the text that it generates, it's AI generated text, like, yeah, whatever. But when you pipe it into one of these voices, it's kind of meaningful.[00:40:24] Like it elevates the material. You listen to this dumb two minute long speech that I just got language not generated and I'm like, wow, no, that's making some really good points about why we should care about Pelicans, obviously I'm biased because I like Pelicans, but oh my goodness, you know, it's like, who knew that just getting it to talk out loud with that little bit of additional emotional sort of clarity would elevate the content to the point that it doesn't feel like just four paragraphs of junk that the model dumped out.[00:40:49] It's, it's amazing.[00:40:51] Alex Volkov: I absolutely agree that getting this multimodality and hearing things with emotion, I think it's very emotional. One of the demos they did with a pirate GPT was incredible to me. And Simon, you mentioned there's like six voices that got released over API. There's actually seven voices.[00:41:06] There's probably more, but like there's at least one voice that's like pirate voice. We saw it on demo. It was really impressive. It was like, it was like an actor acting out a role. I was like... What? It doesn't make no sense. Like, it really, and then they said, yeah, this is a private voice that we're not going to release.[00:41:20] Maybe we'll release it. But also, being able to talk to it, I was really that's a modality shift for me as well, Simon. Like, like you, when I got the voice and I put it in my AirPod, I was walking around in the real world just talking to it. It was an incredible mind shift. It's actually like a FaceTime call with an AI.[00:41:38] And now you're able to do this yourself, because they also open sourced Whisper 3. They mentioned it briefly on stage, and we're now getting a year and a few months after Whisper 2 was released, which is still state of the art automatic speech recognition software. We're now getting Whisper 3.[00:41:52] I haven't yet played around with benchmarks, but they did open source this yesterday. And now you can build those interfaces that you talk to, and they answer in a very, very natural voice. All via open AI kind of stuff. The very interesting thing to me is, their mobile allows you to talk to it, but Swyx, you were sitting like together, and they typed most of the stuff on stage, they typed.[00:42:12] I was like, why are they typing? Why not just have an input?[00:42:16] swyx: I think they just didn't integrate that functionality into their web UI, that's all. It's not a big[00:42:22] Alex Volkov: complaint. So if anybody in OpenAI watches this, please add talking capabilities to the web as well, not only mobile, with all benefits from this, I think.[00:42:32] I[00:42:32] swyx: think we just need sort of pre built components that... Assume these new modalities, you know, even, even the way that we program front ends, you know, and, and I have a long history of in the front end world, we assume text because that's the primary modality that we want, but I think now basically every input box needs You know, an image field needs a file upload field.[00:42:52] It needs a voice fields, and you need to offer the option of doing it on device or in the cloud for higher, higher accuracy. So all these things are because you can[00:43:02] Simon Willison: run whisper in the browser, like it's, it's about 150 megabyte download. But I've seen doubt. I've used demos of whisper running entirely in web assembly.[00:43:10] It's so good. Yeah. Like these and these days, 150 megabyte. Well, I don't know. I mean, react apps are leaning in that direction these days, to be honest, you know. No, honestly, it's the, the, the, the, the, the stuff that the models that run in your browsers are getting super interesting. I can run language models in my browser, the whisper in my browser.[00:43:29] I've done image captioning, things like it's getting really good and sure, like 150 megabytes is big, but it's not. Achievably big. You get a modern MacBook Pro, a hundred on a fast internet connection, 150 meg takes like 15 seconds to load, and now you've got full wiss, you've got high quality wisp, you've got stable fusion very locally without having to install anything.[00:43:49] It's, it's kind of amazing. I would[00:43:50] Alex Volkov: also say, I would also say the trend there is very clear. Those will get smaller and faster. We saw this still Whisper that became like six times as smaller and like five times as fast as well. So that's coming for sure. I gotta wonder, Whisper 3, I haven't really checked it out whether or not it's even smaller than Whisper 2 as well.[00:44:08] Because OpenAI does tend to make things smaller. GPT Turbo, GPT 4 Turbo is faster than GPT 4 and cheaper. Like, we're getting both. Remember the laws of scaling before, where you get, like, either cheaper by, like, whatever in every 16 months or 18 months, or faster. Now you get both cheaper and faster.[00:44:27] So I kind of love this, like, new, new law of scaling law that we're on. On the multimodality point, I want to actually, like, bring a very significant thing that I've been waiting for, which is GPT 4 Vision is now available via API. You literally can, like, send images and it will understand. So now you have, like, input multimodality on voice.[00:44:44] Voice is getting added with AutoText. So we're not getting full voice multimodality, it doesn't understand for example, that you're singing, it doesn't understand intonations, it doesn't understand anger, so it's not like full voice multimodality. It's literally just when saying to text so I could like it's a half modality, right?[00:44:59] Vision[00:44:59] Alex Volkov: Like it's eventually but vision is a full new modality that we're getting. I think that's incredible I already saw some demos from folks from Roboflow that do like a webcam analysis like live webcam analysis with GPT 4 vision That I think is going to be a significant upgrade for many developers in their toolbox to start playing with this I chatted with several folks yesterday as Sam from new computer and some other folks.[00:45:23] They're like hey vision It's really powerful. Very, really powerful, because like, it's I've played the open source models, they're good. Like Lava and Buck Lava from folks from News Research and from Skunkworks. So all the open source stuff is really good as well. Nowhere near GPT 4. I don't know what they did.[00:45:40] It's, it's really uncanny how good this is.[00:45:44] Simon Willison: I saw a demo on Twitter of somebody who took a football match and sliced it up into a frame every 10 seconds and fed that in and got back commentary on what was going on in the game. Like, good commentary. It was, it was astounding. Yeah, turns out, ffmpeg slice out a frame every 10 seconds.[00:45:59] That's enough to analyze a video. I didn't expect that at all.[00:46:03] Alex Volkov: I was playing with this go ahead.[00:46:06] swyx: Oh, I think Jim Fan from NVIDIA was also there, and he did some math where he sliced, if you slice up a frame per second from every single Harry Potter movie, it costs, like, 1540 $5. Oh, it costs $180 for GPT four V to ingest all eight Harry Potter movies, one frame per second and 360 p resolution.[00:46:26] So $180 to is the pricing for vision. Yeah. And yeah, actually that's wild. At our, at our hackathon last night, I, I, I skipped it. A lot of the party, and I went straight to Hackathon. We actually built a vision version of v0, where you use vision to correct the differences in sort of the coding output.[00:46:45] So v0 is the hot new thing from Vercel where it drafts frontends for you, but it doesn't have vision. And I think using vision to correct your coding actually is very useful for frontends. Not surprising. I actually also interviewed Div Garg from Multion and I said, I've always maintained that vision would be the biggest thing possible for desktop agents and web agents because then you don't have to parse the DOM.[00:47:09] You can just view the screen just like a human would. And he said it was not as useful. Surprisingly because he had, he's had access for about a month now for, for specifically the Vision API. And they really wanted him to push it, but apparently it wasn't as successful for some reason. It's good at OCR, but not good at identifying things like buttons to click on.[00:47:28] And that's the one that he wants. Right. I find it very interesting. Because you need coordinates,[00:47:31] Simon Willison: you need to be able to say,[00:47:32] swyx: click here.[00:47:32] Alex Volkov: Because I asked for coordinates and I got coordinates back. I literally uploaded the picture and it said, hey, give me a bounding box. And it gave me a bounding box. And it also.[00:47:40] I remember, like, the first demo. Maybe it went away from that first demo. Swyx, do you remember the first demo? Like, Brockman on stage uploaded a Discord screenshot. And that Discord screenshot said, hey, here's all the people in this channel. Here's the active channel. So it knew, like, the highlight, the actual channel name as well.[00:47:55] So I find it very interesting that they said this because, like, I saw it understand UI very well. So I guess it it, it, it, it, like, we'll find out, right? Many people will start getting these[00:48:04] swyx: tools. Yeah, there's multiple things going on, right? We never get the full capabilities that OpenAI has internally.[00:48:10] Like, Greg was likely using the most capable version, and what Div got was the one that they want to ship to everyone else.[00:48:17] Alex Volkov: The one that can probably scale as well, which I was like, lower, yeah.[00:48:21] Simon Willison: I've got a really basic question. How do you tokenize an image? Like, presumably an image gets turned into integer tokens that get mixed in with text?[00:48:29] What? How? Like, how does that even work? And, ah, okay. Yeah,[00:48:35] swyx: there's a, there's a paper on this. It's only about two years old. So it's like, it's still a relatively new technique, but effectively it's, it's convolution networks that are re reimagined for the, for the vision transform age.[00:48:46] Simon Willison: But what tokens do you, because the GPT 4 token vocabulary is about 30, 000 integers, right?[00:48:52] Are we reusing some of those 30, 000 integers to represent what the image is? Or is there another 30, 000 integers that we don't see? Like, how do you even count tokens? I want tick, tick, I want tick token, but for images.[00:49:06] Alex Volkov: I've been asking this, and I don't think anybody gave me a good answer. Like, how do we know the context lengths of a thing?[00:49:11] Now that, like, images is also part of the prompt. How do you, how do you count? Like, how does that? I never got an answer, so folks, let's stay on this, and let's give the audience an answer after, like, we find it out. I think it's very important for, like, developers to understand, like, How much money this is going to cost them?[00:49:27] And what's the context length? Okay, 128k text... tokens, but how many image tokens? And what do image tokens mean? Is that resolution based? Is that like megabytes based? Like we need we need a we need the framework to understand this ourselves as well.[00:49:44] swyx: Yeah, I think Alessio might have to go and Simon. I know you're busy at a GitHub meeting.[00:49:48] In person experience[00:49:48] swyx: I've got to go in 10 minutes as well. Yeah, so I just wanted to Do some in person takes, right? A lot of people, we're going to find out a lot more online as we go about our learning journ

In der Rubrik “Investments & Exits” begrüßen wir heute Martin Janicki, Partner bei ​​Cavalry Ventures. Martin kommentiert die Runde von Charm. Charm, ein Startup, das sich der Modernisierung der Benutzeroberfläche von Kommandozeilen (command line interface) widmet, hat eine Finanzierungsrunde in Höhe von 6 Millionen US-Dollar bekannt gegeben, bei der Gradient, Googles auf KI fokussierter Risikofonds, der Hauptinvestor war. Zu den weiteren Investoren gehören bestehende und neue Investoren wie Cavalry Ventures, Fuel Capital, Firestreak Partners sowie Gründer verschiedener Unternehmen, darunter Supabase, Foursquare und Fleetsmith. Die Mission von Charm, die vor vier Jahren begann, ist es, die Kommandozeile glamourös, leistungsstark, unterhaltsam und modern zu machen. Darüber hinaus setzt Charm auf Open-Source-Lösungen und hat Projekte wie Glow und Glamour eingeführt, um das Kommandozeilenerlebnis durch eine klare Trennung von Struktur und Stil zu verbessern, ähnlich wie HTML und CSS in der Webentwicklung.