Gerhard Lazu: Well, I think the application boot time could be improved… Because it takes a while for the app to boot. When I say it takes a while, it may take 20-30 seconds for it to be healthy, all the connections to be established… Now, I’m not sure exactly which parts of those would be the easiest ones to optimize. But I think the application going from the deploy starting and deploy finishing, taking a minute and a half is a bit long. So I’ll need to dig deeper, like “Is it when it comes to connecting to the database? Is it just the application itself being healthy? Which part needs to be optimized?” But again, we’re talking – this is like a minute and a half. We’re optimizing a minute and a half, just to put this into perspective. And that’s why I started with the question, “How fast is fast enough?”

Ron Evans: But the worst thing about it though is they didn’t keep going. They stopped. They did one run, they were like “Wow, that was really crazy”, and they shut it down. They needed to keep doing that for 20-30 more years to really learn something as far as science. There’s a big difference between R&D for scientists and R&D for businesses. Scientists, they go in and they do a bunch of research, they spend a bunch of time, they come back and they say “After spending my entire life, I’ve discovered that the answer to that question is no.” And everyone’s like “Oh, Nobel Prize. Amazing.”

Louis Pilfold: So I think lots of languages are “Oh, I’ve got a really big, new idea, and I want to explore that”, and Gleam isn’t that. Gleam is - I was writing a bunch of different languages, and I kind of wanted bits from all of them, you know. For example, when I’m writing Go, it’s like “Oh, I really wish I was writing Erlang right now, because I could do this thing.” Or if I’m writing Rust, I’m like “Oh, this is really annoying, this thing. I wish I had that lovely thing from Go.” Like compile times, or something. I don’t know. And so Gleam is just a mishmash of all the best things, which is why it’s a really nice, safe bet at the end of the day, because all these things have been proven. The type systems - gosh, that’s like 20-30 year old technology. It’s state of the art… From the past.

James Moore: I think you could make an argument that there is more private data on your phone than your laptop… Because people use their phones for personal messages, taking photos, they have their conversations using their phone. But you’re right in the sense that – I mean, they’re both just general-purpose operating systems. They’ve got very similar architectures. That said, you also have to consider how they built the App Store ecosystem. The App Store ecosystem was built really quickly; it was built in the space of one year. And the idea was to get it up as fast as possible, cram it full of features, and sort of things like privacy and security were not at the forefront of those designs. And so Apple’s aim was to deliver functionality to their developers, rather than going “Right, we’re going to make every API super-secure, and super-private.”

The web has a different model. The web by necessity has to have those features built in. Because you can’t have one website randomly accessing the content of another website, or making API calls to the operating system that is not allowed to. That level of security was only born out of 20-30 years of hard-earned experience. The app stores are nowhere near to the same level. In fact, a quote from Apple itself was “Safari/WebKit’s sandbox is orders of magnitude more secure than those for native apps.”

So if you think about the economic incentives in terms of the App Store and web apps, you can see that if web apps were a viable competitor to native apps, then suddenly you’d have all these apps which would then be able to make a decision, “Should we build a native app and have to share 30% of all of our revenue with Apple? Or should we just build a web app?” And so because it’s such a significant amount of money for Apple, they’re heavily economically incentivized to prevent web apps from ever being a true competitor to native apps.

Break: [00:29:49.29]

Dylan Hildenbrand: Steve Ballmer. So there’s that. But a healthier alternative for me was actually just taking every little thought in my head and dumping it onto page. It didn’t matter if it was relevant to the chapter or not; just putting stuff on the page helped.

I found after the first chapter or two, actually taking what I’d written in the outline and copying it into my draft document for that chapter was really helpful. And then while I’m brainstorming my way through the chapter, how am I going to make this connect to that? How am I going to do this? How is this example going to work? I would just take every little thing that I had thought of, “I need to make this happen”, I’d throw it on there, bullet points, and use headings, subheadings, whatever I needed to within the formatting, to kind of make it look like the thoughts felt in my head, if that makes sense.

One of my policies was never delete until I was ready to start writing. And so chapters would frequently be 20-30 pages long, until I’d finished it. And then I would start purging things that were not relevant. And then go through and re-edit my chapter, and then I would submit it to my editor. So that’s a healthier alternative than the initial one that I’d offered.

Saron Yitbarek: [19:54] But yeah, so I really wanted to be responsible with it. And so I had been doing a lot of user interviews, a lot of just talking to users… Because my big thing now is I want to make sure I’m solving a problem. That’s the lesson I took away from the first time, that’s what I want to get right the second time. And so in the process of doing that, I feel like doing user interviews has been an extremely draining process. I’ve cycled through being extremely hopeful and optimistic to being super-depressed, and just very frustrated with the whole process, and burning out, and then getting optimistic again, and then getting really burnt out… And I’ve just been riding that rollercoaster for the last two years. And I decided to do something different this time, where I said “Instead of me trying to get to know my user through customer interviews, and through talking to them, what if I became my user? So what if I picked an area that I’m interested in, picked a user base I’m fascinated in, and I just did the job, and learned firsthand what my pain points are?”

And so newsletters is an area that I’ve been really interested in for the past year or so, and one of my biggest regrets with Code Newbie – I mean, it worked out in the end, but one of my biggest regrets that Code Newbie is not doing a better job of having a mailing list. We had our newsletter, but we didn’t really take it very seriously. It was okay, but it wasn’t a focus for us. And when people asked me “How big is your community?”, it was really hard to quantify it, because we have 100,000 on Twitter, we had another 20,000 on Slack, we had another 10,000 on Instagram… It was just all over the place, so we didn’t have a place that we owned, that was our own place. And a mailing list solves that problem, because that’s the only platform that is actually yours; you own that relationship.

And so I really believe in newsletters, we just didn’t do a good job of it. And I always said that if I ever launched a new product, a new company, new content, that I would have a mailing list. I would have a newsletter and really focus on that. And so I really believe in the newsletter format. I think it has a ton of potential. And I’ve seen over the past four or five years, it’s gotten really popular, especially with Beehive, and ConvertKit has been around for quite some time… Substack popped off I think in 2018, 2019… And so I’ve just been really interested in that space.

And so I said “Instead of trying to go out and interview newsletter creators, why don’t I just start a newsletter?” And so I said “Let me pick a topic that I’m actually passionate about, that I would actually want to write about, even if no one read it.” What’s the thing that you would do when no one is looking, when no one’s paying attention? And I’ve always loved design. I’ve always been fascinated by it, but I’ve never taken a formal class, I’ve never been trained as a designer, but I’ve always wanted to be better at it. It’s always been a topic and an area that I wanted to just be good at. And it’s the one thing that I would do for free, just for fun, because I just really enjoy it. And so building landing pages on my own ideas has been probably my favorite part, because it’s just fun to build landing pages.

And so I thought “Well, what if I teach design to developers as a student myself?” So it’s me going off, spending 20-30 hours, learning on a topic, leveling up on a particular thing, and then turning what I learned into a step by step breakdown, a walkthrough, and then taking that and writing a newsletter and targeting it to developers who also want to level up when it comes to design? So that’s the topic of it. So it’s called Not a Designer because I’m not a designer, I’m a developer trying to learn design skills, and that’s what the focus of the newsletter is on… And it’s been amazing. It’s been such a great way to learn things myself, and actually be a better designer, which is one of my main goals, but it’s also been a really great way of surfacing problems that newsletter people face in terms of growing a newsletter, writing… And I have a marketing person that helps me, and together we’ve gone through and written out all the different problems that we face, all the different issues we have, and trying to see “Is there a product for newsletter creators that we can turn our problems and our issues into?” So it’s worked out really well.

James Q Quick: That’s perfect. I love the adaptive change, and I think if you don’t adapt and change and embrace AI to a certain extent - this is dramatic, but you’ll get left behind. But the reason that’s not as scary as it sounds is that’s been the case with every technological advancement that we’ve ever had. If you were writing machine code 30 years ago, if you would still be doing that, you’d not be very productive. Maybe some of you are, and that’s cool… But we have abstractions, and we continue to have abstractions, where the world that we live in as developers is totally different than it was five years ago, 10 years ago, 20-30 years ago.

[00:06:16.00] So this is just one of those things, and it doesn’t happen overnight. It’s a progression. So I think you look at what’s the easiest way. Can you add an extension to your text editor to give you prompts? Can you go to ChatGPT? I use that almost on a daily basis; not just for code - actually less so for code, but just a creativity standpoint. Like “Give me an idea of a project I can build”, or “Give me questions to ask my Discord” is actually something that I’ve done… So I think that’s kind of the easy way to do it, and I think like where we are now is really, I guess, very similar to what you said about the iron-clad stage… I forget the exact phrasing, but basically the verification phase, where everything you do with AI has to be verified. And that means that our jobs don’t go away, because we have to be developers and have that knowledge to be able to do that verification process… But I think that’s – you’re able to get a lot, but I think you also have to invest a pretty good amount of time into the verification process to make sure that it works, it works correctly, and then if you’re doing it for things outside of code, it also fits your tone. I use it for blog posts and ideas for content and things, but I have to take that output and convert that into something that is genuine for me. So there’s a lot that goes into just confirming, verifying and tweaking the output that you get.

Sunil Pai: By the way, if you want to take that tangent for a bit, I can tell you, as an Indian, it’s easier for me to move to the UK… So five years, you get ILR, and a year after that you get to apply for citizenship, which we are doing soon… Which is kind of weird, for an Indian to get a British citizenship. And there’s a whole lot of context there; we won’t even go into that. But you can get a British citizenship, and then move to the US, and it is way easier for me – like, it takes a lot less time to do that than it would be to move to the US, do the H1B, get a Green Card… That would be like 20-30 years; maybe longer now, by the way. I don’t even know. It’s a mess right there right now. And I’m like, y’all are missing out on like so many people who want to come and like live and actually build great things there. American immigration is weird.

Mike Basios: Yeah, code optimization is not a new thing. If you read research papers 20-30 years ago, everybody would like to optimize and make the code efficient. There’s a lot of tools, like profilers, that help developers find hotspots. The biggest problem in this area is, okay, we profile our code, but how we can automatically improve it, so we make it faster? Typically, this is a very, very manual process, and the majority of the people that work on these areas are super-specialized. And it’s more and more difficult nowadays to find people that know how to optimize the performance of their code, because the programming languages are becoming higher and higher level. Now people write more in languages like Python, JavaScript, TypeScript… So nowadays, the real companies that deal with code optimization are companies from the hardware space, like Intel, NVIDIA, and those, they write specialized software that takes advantage of their hardware, and they show the hardware outperforms, or technology companies that need the scalability. But the majority of developers will not necessarily bother about the performance of the code as an immediate first thing that they need to optimize.

And we have tried, and we have a platform that we helped practically engineers to automate this kind of process, to make it easier for developers to identify places in their code that are slow, and then to optimize it without necessarily having the knowledge that they need, but also do it automatically. Now, the history of code optimization, as I said, it was a very, very manual process at the very beginning; very few people know how to optimize code for specific hardware. In the past, I guess they had to read books and compiler options. Eventually, then you had better and better compilers, so you can use compilation option to optimize your code, and tune the options of the compilers etc. And then you have a lot of profiling tools that help developers also optimize. But still, all these processes most of the time have been manual or semi-manual. And that’s where we see the advances of AI helping this process.

[06:23] And to give you a bit of context how we started our startup - this started after we published the paper in 2018, I think. That was at the Foundation Software Engineering Conference, where we showed that we could automatically help developers choose better data structures. Taking a code, looking at data structures, and optimizing it by giving variations. For example, sometimes in languages like Java, for example, you don’t need to use an array list if you potentially can use a linked list in a scenario that may be better. So we try to do these small changes, and show that we have good performance impact. But the majority of people at that point were manually translating code; rule-based transformation, like regular expressions, “If I see this pattern, convert it to this pattern.” So that is how people have been doing those things with code refactoring tools until the LLM came into that discussion.

Adam Stacoviak: Hearing Landon say this, and then obviously reading Justin’s post, but only hearing so much from him so far, there was something I heard recently from Neil deGrasse Tyson about children in particular. And Landon, I know you said you don’t have any children, but contextually think about this… Imagine you have to - not so much discipline somebody, but guide somebody through life… And let’s say they’re doing things that are wrong, but they have to make mistakes. And so you as a parent want to protect them, so you say “Don’t do that, it’ll hurt you”, but they have no idea about the world. Right? They don’t have any of the experience, any of the context, any of the time that you’ve had on Earth… And the way Neil deGrasse Tyson described this was that, essentially, we’re just conducting experiments through our actions, and trying to figure out how the world works. And the way you describe this PSP hacking, sideloading, whatever it might be, is your version of experimenting with the world, and sort of pushing back on this bubble, this box, this thing that surrounds you. So you’re a person, you’re a human being, and then you’re just trying to figure it out. You got this meat brain above you that’s super-intellectual, but not quite there yet, because you’re – I don’t know how old you are, but your frontal lobe doesn’t fully come into full fruition until around the age of 25. So even then, you don’t have full rationale as a human being should have, as a rational human being, that makes rational thoughts, that makes rational summaries of the experiments they do in life.

So I kind of see, Justin, you, and probably if Jerod and I shared our version of your stories, we’d be similar. How do we all push back on the world and experiment with it, and it push back on us? …and then that sort of – not so much forms us; as you said before, you kind of resist the idea that what you do defines you… And I always say, what I do doesn’t define me, it describes me. Because Adam 10 years ago is not the same as Adam today. But that Adam did something, and it described who he was then. And today’s Adam does something, and it describes who – kind of not who he is, but what he does now. So what I do does not define me, but it describes me.

[18:31] But this pushback on the world is just a natural thing to experiment. And we’re all just sort of – some of us more, some of us less curious about how the world works, and so we are willing to obsess further and farther than others might be. And that might give us tendencies to go into areas where we’re allowed to experiment way more. And the software world in the last 20-30 years - that’s been the epitome of exploration and innovation. So that’s the best place for those kind of mines to gravitate towards.

You wouldn’t gravitate towards wood building, because that’s kind of like set in stone, for the most part. There’s been tooling upgrades and stuff like that.

Techno Tim: Yeah, huge fan of POE. I feel like they’ve breathed new life into a technology that’s been around for, I don’t know, 20-30 years, probably more. I mean –

Adam Stacoviak: Yeah, let’s do it for 2030.

Jonathan Norris: Yeah, I’ll go for it. My unpopular opinion is that WebAssembly runtimes will replace container-based runtimes by 2030. The advantages of WebAssembly, with its tight security model, its very fast boot-up time, scalability at the edge, with much smaller footprints, its portability across environments will really drive a shift away from container-based runtimes, for things Kubernetes and edge workloads by 2030. There’s a ton of energy around making this happen within the WebAssembly community.

Matthew Boyle: I think I think you’re right, there’s definitely overhead here, and there’s toil… And to me it doesn’t really make sense. If we’re talking about distribute systems again, in that sort of world, I don’t think it makes sense until you’ve got, I don’t know, 20-30 engineers to maybe even consider this.

I think some companies start as microservices, and can be really successful there. I think you have to really know what you’re doing to do that. But for a lot of companies, you’re probably better off starting with like a monolith, and kind of just focusing on delivering value. A lot of this stuff is shape and structure to how you can make changes safely and deliver value as you scale. If you’re comfortable, and at the moment your goal is to ship, I definitely – I think it’d be great for everyone to read about this, and just make sure they kind of in their head have a clear path to get here maybe when they need to… But I think you’re right, there’s tons of overhead that comes with this, and it’s not really necessary until you hit – like, if you hit a point when your team are stepping on each other’s toes, and you’re waiting for that pull request by that team to be merged, for that one to be merged, and perhaps you’re seeing bugs or issues or misunderstandings around requirements, that’s probably the time you should go “Hang on, this isn’t working for us. Maybe we need to think about the way we plan and ship software”, and domain-driven design is a really good place to start.

[34:26] If you’re iterating fine, you’re shipping fine, you’re not really seeing many issues, you’re doing a great job doing what you need to do and you’ve got a really great sort of line of communication with the folks who are making decisions, it’s probably overkill at this point, I think.

Kevin Ball: Keep projecting that out and in like 2030 we’re passing them.

Gerhard Lazu: I mean, that’s what we used to do 20-30 years ago; surely we have moved on since then, right? [laughs]

Jerod Santo: Nick’s at negative four… So I will say, it was not a creative mind. What I did was I took a real headline and I changed the values. So it’s actually true in a sense, except for it’s not 50 billion, it’s 10 billion, and it’s not 2030, it’s 2023.

Chris Benson: [20:30] As we talk about the fact that attention is used in here - and I know in some of the discussions around it, it’s referred to as cross-attention… What is cross-attention as a form of attention? Does that just mean different modalities coming in, or how would you define that?

Taylor Dolezal: Disney is a huge place, and so asterisk is really – that’s the “It depends”, very general answer. But on my team specifically – it was pretty split. I think that we really focused on using GitLab… So both options were available to us. And Disney was very good at kind of locking things down. They have to be, with movie leaks, and everything… When they store pre-release content in the cloud, they intentionally lock themselves out of it. So they have to call the cloud provider if something goes wrong. They rely fully on machine-to-machine interactions with one another.

It was really interesting too, because the culture at Disney was very much - the production culture, at least - focused on you had seniority based on how close you were to pre-release data. Your title really didn’t matter as much, which was the most interesting part; it was all about how close you were to the content, and that was kind of how the hierarchy developed, at least in the culture. So that makes sense, especially if you wind the clocks back 20-30 years, that makes a little bit more sense… But that’s definitely permeated, up until the time I left. It might be different now, but that was very much the case, then. Just a really interesting thing.

Chris Benson: [20:30] So I’m gonna say nice things about what you’re saying, and I’m gonna do this despite the fact that you’re my co-host on this… So I would say this to anybody… No, I think that you have the benefit of having been a software developer as long as you’ve been a data scientist, and so you’re able to see both sides of that. I think that’s often absent, that perspective.

So what you’ve described - you’ve picked some specific technologies that you want to use to support CI/CD efforts, which are fine, and I think that there’s a whole bunch of different options there that are all more or less equally good, with some pros and cons to each one, as normal… But you’ve integrated it so that you’re not only testing the software, but you’re testing your data by testing how that data is running through the model and inferencing. So that is a very, very cohesive system. Unfortunately, here’s the bad news. I think that your approach is a little bit more of the exception than the rule in the broader industry out there. I’ve seen this at a number of organizations, where the skill sets of understanding that are still kept kind of in separate groups, separate departments, maybe even whole separate organizations… And I think the benefit of being working for a relatively small organization, not a giant Fortune 500 thing, is that you’re able to keep everything close enough together and your expertise is able to intertwine to solve that well. And I think that that is a good guideline for others to look at.

If you ever find – I know you have all this spare time on your hands, but should you ever find it, I think maybe actually publishing a little thing on that would be a useful tool for people to kind of see how you’ve approached it, other than just listening to the podcast here… Because you’re kind of hitting – you’re hitting those software best practices, and you’re hitting the data science best practices together, and treating the model as an artifact that needs to work for testing in that software deployment process and delivery. So anyway, I love what you’re doing there.

Fred K. Schott: For the MPA story, it’s much more about you’re getting the server to generate a lot of the markup for you. And that’s the big benefit for performance, is that you’re not running an app on a low-powered phone, on a bad internet connection; you’re streaming HTML down, using the model that’s kind of existed for the last 20-30 years around web development, of the server is doing all the work. The frontend is just making it interactive where you need it.

Miško Hevery: So we started working on Qwik, and very quickly we basically realized exactly this, is that the third-party code is kind of ruining the party here, right? And so the realization we had is that if you just make a blank page with nothing on it, and you add Google Tag Manager by itself, it puts you at the precipice of no longer getting 100 out of 100 on Google Page Speed score. And so if that’s the situation, and that’s just one of 20 other things you have to add, you’re not going to win this battle. And so Partytown was born.

The idea is, you take third-party code and you run it in the web worker. Now, that idea is not new, right? There’s nothing clever about that thing. That’s like an obvious thing. The problem is, how do you do that, because the web worker doesn’t have DOM, and all of these scripts do something like document.title, or they say document.eventlistenerclick or like whatever they do right in there. And so they don’t have DOM.

[52:01] So people have tried to make fake DOMs in the web worker, and that doesn’t really work, because they kind of go out of sync, and a lot of things actually want to measure things, like “Oh, how big is the box? And where am I on the page?” or things of that sort. So none of that stuff really works if you have kind of a fake DOM. So you need to have a real DOM. And one thing you could do is you could make a proxy, meaning that whatever operations you do on a web worker, you also do on the main thread. And by proxying everything over, you can just have the script running inside of the web worker, and if it says, “What’s the document.title?” you just go to the main thread and say, “What is the document.title?” and then you return that back.

Now, all of that work’s easy, except for one tiny problem… And that is that the communication channel between the web worker and the main thread is asynchronous, meaning that if the web worker says “What is document.title?”, by the time you come back and figure out what the title is and report back, it’s too late; the code has executed past this point, and it’s probably crashed, because you couldn’t really answer the question correctly. And so the magical bit that Partytown kind of figured out is how to make a synchronous call from the web worker to the main thread.

So we’ve figured out a way to block the execution of the web worker, so that we can go and talk to the main thread asynchronously, and then when we come back, we can resume running the web worker with the script from where we left off. So that’s the whole magic, right? And so we put this together inside of Partytown, and Partytown is great, because people will just add it to their website and they’ll increase their score 20-30 points on Google Page Speed score just by adding it. And it’s not like you have to change anything, it’s just third-party scripts. And so just moving them over to a web worker can have a huge impact on your performance.

Raman Lally: So that’s really the main thing you have to look out for. And then obviously, use types. I was like, I don’t know, the first few schemas I ever worked on, you end up with these God types, where it’s like this enormous object with like 2030 fields on it… People are like “This is really nice. We have a huge object” and it’s like “No… We don’t want a huge object. We want smaller types that are easier to compose and reuse and whatnot.” I mean, obviously, the basic schema design principles come in, for sure.

Shawn Wang: Yeah. The thing about Vite - it’s gonna be interesting whether or not, when we stand here and we do this again in 2030, whether or not we’ll be talking about Vite or swc. Because Vite has the current momentum right now, but it was never really the intention of Evan, the author of Vite - and the author of ES Build, actually; both are called Evan - to be the core toolchain of everything. He actually kind of called it a proof of concept; an existence proof that your build tool is gonna be faster. Whereas swc is meant to be more of the platform.

If you look at Next.js, they’re not adopting Vite, they’re adopting swc as the sort of Rust-based platform of choice. So I think it’s a very interesting debate right now. We may have just rushed to Vite, just because it was the first to be a fully-features bundler, with a really good dev story… But long-term we might be shifting to swc just because the architecture might support more things that we wanna do. I don’t know. This line of thinking is about two years old now, and I haven’t really engaged with either of the authors to check my assumptions.

Johnny Boursiquot: I mean, I will say that over the years we’ve gotten more – well, let me put it nicely. We don’t worry very much about CPU and memory and disk… Things that used to be expensive 20-30 years ago. Not so much now. We take these things for granted now.

Peer Richelsen: Yeah. [laughs] It also sounds cooler than 2030.