Brendan Eich: Definitely. We have to experiment, but as a business we also have to figure something out, because we can’t just keep raising venture capital, as Mikeal was joking earlier. And I think it should be possible to have a going concern… You mentioned where the money goes today, and it goes to ads, and ads are kind of compromised by this indirection through third parties you can’t trust, and that’s a problem. So anything we did that was replacing that means of getting funds to publishers would have to be less delegated, more secure by design, and that’s what we’re working on. It’s still kind of a two-edged sword, because people hear ads and they just think “Yuck!” or “Doesn’t that put you in conflict with your users?”

That’s why we say the user should get the same revenue share we get - 50/50 between us and the user as far as the amount. It’s not like we’re trying to say “Only to us.” We could even give it all to the user at first. At some point we have to sustain ourselves, so I’m not sure what the balance would be. We’re starting with 50/50 because we wanna align the user’s interest with ours. And if we do a good job defending the data, then I think many things are possible. But ads are the thin edge of the wedge. So much is misspent on them today that it’s attractive to try to bend the system or form it a bit, and that’s why anything we do would be privately matched – I haven’t talked about this, but we wouldn’t do any cookies or signals for Brave users. It would be all based on device matching. It’s like you get a catalog of available ad URL with two or three keywords associated with each. Then, based on your local machine learning, you evolve a set of two or three keywords that might be good to promote, and you’d match those against the catalog. That can be done with no signals out; you just download the same catalog everyone downloads once a week, or whenever the campaigns roll out.

That’s just one idea. We have the zero knowledge proof protocol, Anonize-based protocol for confirming the ads were viewed. Because at the end of the day, all that the marketers care about is that there were millions of authentic impressions; they don’t wanna identify each of those people by name. Some people do - the middle players who build data profiles do. They’re the ones we want to actually go away. I’m sorry, but somebody’s gotta lose. Couldn’t happen to a nicer bunch. I’m friends with some of them… But there’s too many of them, they’re taking too much money out of the system, they’re running away with your data and privacy, and they’re letting malware in. When I tell a story, I like to not make it sound like everybody wins. Not everybody wins.

Amal Hussein: …effort, you know, that they did. And the reality is - sure, somebody using LLMs… By all means, I still see myself as being senior to that person, by a huge majority… I also think that having a software background with AI just puts me in a completely different category. It exponentiates me in the same way that it exponentiates that other person who has zero knowledge. But it’s exponentiation, so there’s a high log factor to account for.

Shawn Wang: Yeah, so I actually tried to leave solutions out of this post, because it’s been covered elsewhere, and I haven’t identified as Dev Rel for maybe a couple years now. There’s a bunch of solutions out there. I do think just the straight, job hasn’t really changed. I think what the removal of free money has led to is basically we can no longer get by with lack of accountability in Dev Rel. It’s probably a good thing, it’s probably something that we needed. And so what I tried to do in the post is to list out the smells of what ZIRP Dev Rels looks like. And so I tried to use that as a checklist for people in the industry of like “If you were doing this, there is no longer any appetite for this.” It is no longer okay to do – let’s just call it free-tier Dev Rel, for example.

[00:35:52.13] You only talk about how to use your company’s free services, and have blissfully zero knowledge of anything paid, because that doesn’t serve the company’s needs… And actually, more so the point, it doesn’t actually serve the customer very well, because you don’t know your product.

And there was a lot of free tier Dev Rel in ZIRP… Because it’s easy to talk about something that you can adopt for free, and it’s easy to get applause for something that’s free. The hard part - and it was really challenging your skills - is saying why your company’s products are actually worth real money. And people who obviously were successful at that were probably more valuable to the business anyway.

So yeah, there’s a lot of thoughts… So at the end of the post I linked to Lee Rob, I linked to Sam Julien, who used to be VP of Dev Rel at Auth0, and I linked to myself as independent thoughts. I think everyone’s basically – the common consensus, let’s just say, is that Dev Rel moves into developer experience, which is kind of an annoying rebrand. Every industry likes to rebrand itself. In DevOps there’s this ongoing rebrand to platform engineering. Same thing for Dev Rel.

Natalie Pistunovich: Once [unintelligible 00:28:50.13] not fast. But I think the current state of things generally, to answer your question - the comparison to Google, the way that it gives you this very personal thing is cookies. It collects a lot of data on you. Only the open data, only the data that you opt into give. Because you opt in to be on the internet, you opt in to be on the social medias, you opt in to have a cell phone, and so on.

It’s very hard these days not to opt in to give this data, and if anyone is good at that, it’s Germans, and even they give data to some level about themselves. And I think that right now, specifically, the ChatGPTs do not collect any data like this and do this personal thing about you, but one of the leading engineers/scientists/people who work there, called Andrej Karpathy - I will add his Twitter on the show notes as well… He describes in his Twitter bio that he’s working on a sort of a Jarvis at Open AI. So I think this one will be similar to what you have in mind when you think about that movie, because that movie starts with him activating the software computer - I forget what exactly - and then it kind of browses all the emails, all the internet presence he has, but also all the private things… I don’t know, things he typed and never shared with anyone. So that’s why it’s so personal. So it’s even more personal than Google right now, but it’s also an opt-in thing. And with zero knowledge, I’m guessing that this is something similar to what Andrej Karpathy means when he says he’s building a sort of Jarvis. But he also uses the word Jarvis, and not Her.

Michael Malyuk: It depends on how much you want – if there are components that cover your use case and you right now have around 20 different components, then you need almost zero knowledge about the front-end development. If you know how to stack up the HTML as text, then you’re good to go. But then while we were creating the tool, we made it extensible, in a way that you can create your own components.

For example, if we don’t have right now support for the video, you can create your own components to render video, and connect it to, for example, checkboxes that you can use for classification. So in most cases we try to cover 80% of the most common cases with the companies that we develop ourselves, but then we also give you an ability to extend it for your particular needs.

Richard Feldman: The first resource I recommend to everybody is just the official guide. If you go to elm-lang.org, then it’s got a nice walkthrough that just gets you start to finish. It’s pretty short, so that’s a pro and a con. It’ll get you up and running, but it’s not super in-depth. I’m writing a book - shameless plug - “Elm in Action”, which goes into a lot more depth, and it’s pretty much designed at people who know JavaScript, at least to some extent; it doesn’t expect that you’re a JavaScript master by any stretch, but it uses JavaScript as sort of a comparison point. I think if you’re coming from JavaScript, that should be a nice introduction.

If you prefer the video thing, I’ve also got a course on Front-end Masters, which I recently updated for Elm 0.19. I’ve got two courses on there - one is Intro to Elm, which is basically a day-long course that gets you from zero knowledge of Elm, at the beginning, all the way up through building an application and working on a larger Elm codebase that does single-page application stuff, and HTTP and all that.

Then the advanced course - maybe come back in a couple of months if you’ve been digging at Elm, and get into some of the really cool, advanced stuff.

Carlisia Thompson: [01:04:05.17] Yeah, we can talk in terms of many, and I would never disagree with that… But we have to look very closely and explore what really is happening. We can assume anything… Because you can say, “Well, there are many”, and a lot of people who are working with innovation are being forced to take English, but is that in a private setting, or is that being taught in school? Is it free? …that’s what I’m saying, because if it’s not free and accessible to everyone, then people are being excluded, and I think some of those people might be developers that could otherwise be learning, or maybe having an easier time to learn the language and how to do things properly, in other words how to take advantage fully of what the language has to offer, if that wasn’t something that they were struggling with, or they had to pay a fortune for.

So in that sense, unless it’s being provided for free to all the potential programmer population… But in any case, that is an assumption, right? I have zero knowledge about China in that regard. So if that was the case, just take for example the survey that the Go language team puts out every year - that survey is in English. So anybody who is using Go or is interested in using Go and doesn’t know enough English to read that survey, won’t be accounted for, right? Their experiences, their opinions won’t be accounted for, because the result of that survey goes right back to the Go language team for them to make decisions on how to develop the language itself and everything around the language.

Jerod Santo: How would you start? Say you want to become a software developer with zero knowledge today, and you are looking for a starting point. What would you try?

Adam Stacoviak: [00:53:43.07] What in the world is involved in building this? I mean, I just look at you – so I don’t want to downplay you. I don’t want to say “Drew is just…” But just for the sake of just this conversation, you’re the person who taught yourself how to design in Photoshop before there was layers. And it’s not saying that you can’t learn, but you’re somebody who came from literally a zero in terms of like knowledge. You didn’t have the design skill, you gained the design skill. You didn’t have the engineering skill because you didn’t really want to; you weren’t interested in it. You gained that. And now here you are, creating a freaking bank. Like, come on, Drew.

Narayanan Raghavan: So I almost want to draw a Venn diagram with overlapping circles… But there’s a little bit of an overlap between DevOps and SREs, there’s an overlap between SRE and platform engineering… And I think it’s important to recognize it. It’s important to recognize it because depending on the team, depending on the company, depending on the products that the company has etc. no one person can (it’s just not humanly possible) remember and keep everything in their head. We should be way past the hero worship; we should be way past knowledge in silos. If we still have knowledge silos, then we have a different problem.

Now, assuming that’s not the case, no one person can wear all three hats. They may be capable; it doesn’t mean it makes sense, both from a work/life balance perspective, or even from an ability to actually do justice to the things that start to matter.

So for example, somebody in the DevOps role, I would want them to focus on making sure that they have good CI/CD practices, good build pipelines, release hygiene etc. Somebody in the SRE role, I would want to see the ability to create systems that can scale, the ability to make sure that you’re not snowflaking your entire fleet, and making sure that the changes that you push out from a fleet perspective, and the capabilities that you put out actually work for the entire fleet, and being able to think about security in the same way as you think about reliability.

From a platform engineering perspective, this for me is being able to think purely from a building blocks perspective, to say, “What are some common things across all my engineering teams, all of the development teams? And what is it that I need to focus on to make sure they are successful?”

Now, some of those common pieces might land with an SRE team. Some of those common pieces, like internal developer tooling, for example - it doesn’t make sense for it to land with an SRE team. There are services that you might use in production that need to scale, that might land with an SRE team. There are services that you need for development purposes for my day-to-day job; it might land with a pure platform engineering team. So at least in my head, that’s how I separate it out.

Mike Riley: That’s right. And the other nice thing about what we provide with the book is - again, we wanted to get people familiar with the concepts and the technologies, but also infuse them with ideas of where they can go next. Every chapter concludes with “Okay, we’ve given you this. This is what we’ve done. This is where we’ve come from, and this is where we’re going. But in the meantime, here’s a couple of other ideas you might want to build upon.”

So what I’m looking forward to is seeing what our readers of the book expound on and create. Because I think that’s where it gets more exciting. I’ve had ideas of being able to take that Pi zero, for instance, and tying it into, say, a sprinkler system.

[00:40:05.01] And that way, based on, let’s say, the humidity, or what the soil density of water reading in there - alright, it looks like the grass needs watering, so let’s turn on the sprinkler, and let it run for a certain duration, and then check the soil density again. If it looks good, then go ahead and turn it off. So all that is possible. And again, the technologies and the languages that we use - it can be all built straight from the knowledge that is picked up by the book, and by just Go programming in general.

Johnny Boursiquot: I started dipping my toe into teaching because I wanted to learn more about the very thing that I was teaching about. So if you ever want to put yourself in sort of a challenging situation, sign up to teach a Rails Bridge, or Go Bridge, or Clojure Bridge… I mentioned bridges because that’s where I got my start. I started as a TA, because I wanted to – even that, starting as a TA, because I wanted to be able to say “Well, crap… I’m running Ruby, I’m learning Rails, and there’s a Rails Bridge coming up… I know, I don’t know a lot about Rails still, but I know more than somebody who’s never done Ruby before.” So I’m going to use that as a lever. I’m going to use that as a means of leveling up in order to be able to answer questions.

[56:37] So I sign up, and I have two weeks or three weeks to prepare as much as I can in order to be a TA at this workshop… And what I do for the next two or three weeks, I sit down every day, I’m trying to hone my skills, I’m trying to learn, I’m trying to – I’m reading, I’m consuming content. I’m literally – because I don’t want to, one, come out looking like a fool, because when somebody asks me a question, or two or three or four, and I have zero answers, that’s embarrassing. So I don’t want that to happen. But also I’m like “Okay, I’m doing this because I have some interest in being able to teach people.” You kind of have to want at least that part; you kind of have to want to do that. Because again, teaching is not for everybody, so you kind of have to have a desire to do that in the first place. I’m like “Well, how do I not only learn information so that I can relay it, but how do I learn the art of teaching?” I’m not professionally trained in teaching, and there’s people who go to school and get degrees in teaching, right? So how far can I get without going back to school and saying “I want to learn how to teach properly”, or whatever. So how far can I get?

But then those things you find out - okay, we all teach each other all the time, whether or not we realize it. You walk across somebody in the street, an old friend, whatever it is - we’re always teaching each other in some way. We don’t call it that, but we’re communicating. We’re relaying information, conveying information… Depending on how I convey information to you, it may be a useful exercise for both of us, or it could be something that leaves a poor taste in my mouth. So trying to find, okay, what’s the best way to deliver this knowledge I’ve just acquired, and I just need to be able to sort of convey that to somebody else?

I mean, for me, my a-ha moment was when I literally basically volunteered to go explain the notion of object-oriented programming to a roomful of people at a Rails Bridge… To a roomful of people who didn’t know what those words even meant, like “What does that mean?” and whatnot. So I started using sort of a cooking analogy, because during that time I happened to be learning how to cook, and more than just boiled potatoes and eggs. So I happened to be learning how to cook, and I started using kitchen analogies, like “Oh, there’s an oven, you put things in it, and it has a timer, and this is how you relate these things together.” And it was a roomful of people who clearly knew about cooking… So you saw people like with the a-ha moment; they’re realizing “Oh, okay, I get it now”, because I was able to say “Okay, well, I can’t use technical terms to explain these technical concepts, because I’m just gonna leave people just with a blank stare in their face. What is something that most everybody in the room is going to be able to connect with and relate with? How do I translate those technical terms and concepts into something they know in the real world?” The moment I did that, and I saw the effect of teaching that way, I was hooked. I’m like “Oh man, I want to do more of this.” The gratification you get out of that, when you’re finally able to take something that is fundamentally difficult to grasp without years of experience, and you can boil it down to something that is consumable for the layperson… I mean, it’s an incredible feeling. So the more you pursue that, to me, that was my arc. That was my journey into it. That is why I really wanted to do more of that.

Johnny Boursiquot: [00:09:58.17] Well, I mean, that’s the thing though, right? They’s saying that folks are actually closing tickets because they got the answer they wanted. This is not our grandpa’s AI, where you’re going through the phone tree, pressing all the buttons, trying to press zero, or yelling at the thing, saying “Hey, operator, give me a human.” This is not the same thing at all. These days, these things are – I mean, if they have a knowledge base, and you unleash an agent, an LLM or something on that knowledge base, presumably it’s the same thing that the human that you otherwise would have been chatting with is doing, right? They’re looking up a way to give you an answer that is approved by the company. They can’t wing it, so they have to use a for reference. So if you give that reference to an AI bot, presumably it does a much better job, much more accurate and faster job of giving the right answer to the user. And that is one of the sort of use cases which I can appreciate. But the fact is that it still leads to layoffs. And these are the kinds of jobs that I think are being impacted the most, right?

Nathan Sobo: …nobody sue us… But a tiny bit of code from Xray involving some of the core data structures around the buffer, the text buffer. I’m not sure if we either made its way in or we derived it based on that knowledge, but most of our approach to UI that we took an Xray we’ve discarded, because it didn’t work, actually.

So a big thing that Antonio and I did in those first several months, nights and weekends working on Zed was like taking a step back and figuring out, “How do we do a graphical user interface in a language with the constraints that Rust imposes around ownership?” Where kind of everything needs to have one unique owner, and it’s very – you know, once you’d have everything be this directed graph, where everything is downward, a tree structure of ownership. And of course, there’s library types like [unintelligible 00:25:33.18] and stuff that allow for shared ownership, but every time you introduce one of those, you introduce awkwardness, and the potential for runtime panics, if there’s like a double borrow etc.

So like that was the first big problem we needed to solve, is like “How do we do UI?” And so initially, the foundation of GPUI, we thought, “Well, maybe what we could do is still have Electron do the rendering for us.” Like, just that last little bit. And so the core of Zed was actually – we tried a couple different approaches. One was embedded into Electron as a library, and then the other was actually running as a separate process… And the views would render JSON, which would then be consumed by React on the frontend, and would render the UI.

[26:21] And so we put all this work into the core of the system written in Rust, with painstaking attention to our algorithmic bounds, and etc. And then the JSON would get to the JavaScript, and we’d just throw it all away immediately… Starting with parsing that data, and then recalculating styles, reflowing the DOM… Like, no matter what we did, we just couldn’t achieve the performance that we wanted, even starting from zero, and doing as much as we could of Rust.

And so at some point we were just like – I don’t know, I was afraid of doing our own UI, honestly, to some extent, because it just seemed daunting. It just didn’t even seem like a reasonable thing to try, to me. But at some point, it was just like “Well, there’s no point in doing this if it isn’t super-fast… And this is not fast.” And so finally, it was just like “We have to abandon Electron. We have to do the graphics ourselves.” And I’d never really done any graphics programming. We played with it a little bit during Xray, like doing WebGL stuff… So yeah, we started with this Rust crate called Pathfinder, which is - Patrick Walton wrote it; really cool ideas in there about doing like a Bézier curve, 2D rendering on the GPU… But that was too slow. And so finally, we just boiled it down to “Well, what do we actually need to draw? What is a 2d UI?” And it boils down to some rounded corner boxes, with borders, and padding… Drop shadows… We need to get glyphs and icons on the screen… You know, there’s like a pretty limited vocabulary that we knew we’d need to have, and so we ended up just like writing our own shader code. And to this day, we have like maybe 600 lines of shader code.

The UI library is pretty large, but in terms of the actual code that needs to run on the GPU, because the primitives involved in a 2d UI are much simpler than a 3D game with photorealistic waterfalls, or whatever… It’s actually pretty simple the code we have to run on the GPU. It’s all the code around that, that efficiently gets from a mouse click to what happens to pixels on the screen.

A lot of the innovation I think is like code that runs on the CPU, that kind of gets that data into the GPU’s memory. But yeah, that was the path of just relentlessly saying, “Until this is fast, we haven’t solved the problem, and we’re going to do whatever we need to do to get there.”

Adam Stacoviak: For sure. It’s the ultimate no excuses, right? If I can give you an environment that I know works, then it also requires you zero effort really, aside from understanding Codespaces and how it works, some knowledge basically that you’re gonna pick up no matter what - it’s the ultimate saying like “Hey, you don’t have to change your machine at all. You don’t have to do anything to your local Postgres, or your local Homebrew, or wait for a Homebrew update to finally run and be done…” You know, whatever happens when you run Brew updates; no offense to Homebrew, I love it, but there are some challenges when it comes to the ceremony of spinning up any project, whether it’s your own or somebody else’s. And all those hurdles are just more hurdles to contribution, really.

David Flanagan: Yeah, that episode was serendipity as well. Chainguard were lined up to compete against another team, who unfortunately had to drop out because a couple members got Covid… And I tried not to cancel the episode, and Chainguard had been hiring way out lately. They went from zero people to 50 people in a matter of months… And I was like “Surely you’ve got enough people for two teams.” And they were like, “Okay…” So we managed to get two teams from Chainguard.

That was another great episode as well. It’s fun, especially because it brought that dynamic of colleague versus colleague. And I say it’s not competitive, but when you’re coming up against your teammates, you make it a little bit extra competitive, and I feel like that’s a really good one to watch as well.

If I were going to recommend any other episodes, there’s always two that I love to mention as well. There was one episode - and again, complete serendipity - with Thomas Stromberg who was an engineer at Google and maintainer for minikube, so really strong Kubernetes knowledge… And Kris Nova, also famous in Kubernetes for their hacking and all the things that they do with Kubernetes clusters.

Kris Nova did some kernel hacking, and eBPF, and recompiling glibc to hide processes… Really crazy stuff. But she was up against Thomas Stromberg, who had also done forensic analysis of intruder detection machines at Google. And he busted out this kit, took a snapshot of the desk and all changes in the last 48 hours, and I don’t think anyone else on this planet would have been able to fix that cluster. Thomas did.

I always tell people to go watch that episode, because there is a lot of lessons to be learned from that. I keep meaning to write some of them up in a blog, but time is never on my side… But I always encourage people to go watch that episode.

And another really good, fun one, if you wanna see teams enjoying it and not taking it too seriously, was the RedHat vs Talos Systems. They’re now Sidero Labs, but their RedHat team removed the executable bit from chmod, and kubectl, and `perl, and a whole bunch of other utilities, and the Talos team actually couldn’t execute any commands on their machine. And I won’t give away the fix on this, because people may be sitting there thinking “How would you fix that?” Either go watch the episode, or google the answer… But again, another episode where it’s just light and fun, but you learn a ton in the process of seeing how cruel people can be with these systems.

Jerod Santo: He had yellow sticky notes all over his desk for different– I don’t know. I would never look at his sticky notes, but he was not going to document anything. And he was the guy who would just know what was wrong. It was almost like he intuited what had to happen. And I sat there and I observed this for a little while, just thinking, “This person’s amazing.” And he is. He is very good at what he does. And then I finally got to where I started asking him questions. I’d be like, “How did you know that?” And I started to prod, and I started to pull, and I learned so much about the system, about how to debug and troubleshoot, things that he skips over because he understands – he’s seven steps in, and I’m still on step zero. And it would be amazing if everything that was in his head, or at least some sort of synthesized version of what’s in his head could be accessible to me async, without having to sit next and prod him, and have both of us– and today we don’t even sit in the same office as our colleagues, right? So I see the value. I see how easy it is to silo this domain expertise, the systems expertise, that one person who you always have to call because they’ll know what’s wrong… And then all that knowledge just lives in these little silos of their brains, where if that’s shared in a repository - just so much value. So much value.

Adam Stacoviak: You know, I can really appreciate too, Feross, that you’ve been able to build upon what you’ve already put out there before. You’re not starting from zero with this one. You’re sort of layering on the things you’ve already given out there freely in open source, and you’re also layering on your personal knowledge base to build this next big thing… I think it’s really admirable, so congrats on that.

L Körbes: So there are some metaphors that you can’t use in a different language, because they just make no sense. For example, the first thing that just popped in my mind - there’s a metaphor in Portuguese that was like “Water’s soft, rock is hard, knock-knock and it breaks”, something like that. Like, yeah, sure, if you think about it, you can understand, but I wouldn’t use this idiom to an English-speaking audience… And likewise, there’s a bunch of English idioms that just do not translate to Portuguese.

Sometimes you learn something with a metaphor like that, but you can’t use the same metaphor, so you need to find different things. Most of the time, that’s easy, but some concepts are really hard, no matter the language.

Teaching interfaces, polymorphism, pointer methods - that stuff was hard. And not necessarily because of the language, but just because it’s the kind of stuff that once you understand, you understand, but until you do, it makes zero sense… And I find it hard – so I climb the stairs and make easily-digestible steps; it’s the kind of thing you either understand the whole thing, or it makes no sense.

I think interfaces are probably the most difficult thing to explain, especially because they don’t map to other languages; in Python or Java, what interfaces do is kind of different, so you can’t really catch that other knowledge and use it. You have to kind of do it from scratch. Yeah, that gets a bit tricky.

Divya: It’s a really good point, because I think one of the things that – sometimes people think that they have to move companies, because usually it’s like “I’m unsatisfied here” or I’m burnt out”, or “I wanna do something different.” But I think it’s a really interesting way of looking at it… The way you mentioned it, Kball, which I feel is a very healthy and reasonable – not to say that other reasons are unreasonable, but this is a different way of looking at it, where you’re the champion of your career trajectory.

I think sometimes people stay at companies because they are comfortable, like Amal was saying… And that’s fine, but if you know what you want, and you know what’s next for you, and the place that you’re at isn’t gonna offer you that, then that’s actually a good reason to leave, to be like “Let me go find something else.”

And also, maybe if you’re able to identify the type of things that you enjoy doing, so if you’re someone who is a small startup person who likes to build and own things, and take them from zero to one, not necessarily scale, but just build very quickly, and the company grows and is no longer at that early stage, then maybe you’re like “I like early-stage”, and you jump to the next early-stage thing, and you just keep doing that, because that’s something that you enjoy doing.

I think people often – yeah, I think it’s very common to just see yourself going through the titles as a way of progression, but a different way of looking at it is what do you wanna work on and how do you wanna grow your own skills? For example, I’ve been working on frontend for a long time, and that’s been my focus, but I’m realizing that I’ve actually never worked extensively in my professional career on backend stuff… And that’s actually sort of a black hole sometimes, because unless it’s in JavaScript, I have no idea what that’s like. I’m getting a lot of the experience now. I had to write a bunch of Rust code and figure out how to manage my Docker containers, and run tests in a separate environment… And that’s a whole other experience that I’m realizing I’ve been not privy to because I’m focused so much… And it’s a sense of like stepping back and being like “Okay, what else is there? How else can I deepen my knowledge?” Because it’s also sort of an exploration.

Going back to a previous point - it’s exploring “Okay, let me go try this for a while…” And then who knows - you might do it and hate it, but then you have the knowledge now that you hate it, rather than never knowing a thing because you focused so much on the career trajectory that you’re going down, and the titles, and not wanting to lose that track. So I think it’s just a different way of thinking about it.

Daniel Whitenack: It’s kind of like most programmers don’t write every single line of code from scratch when they’re creating a new application. There’s a lot of copy and paste that goes on, because they’ve done this before, they’ve done that before, they’ve created this service and it just needs to be slightly different this time around… So they never start from scratch; they kind of copy a bunch of things over. It’s very similar here, in the sense that yes, you can in many cases take a model that has not been trained on any data yet, and train it to do a certain task.

Let’s say that we want to translate text from English to Hindi. What we do is we get a parallel corpus, so we’ve got a bunch of examples of English phrases, and then a bunch of examples of the corresponding Hindi translation of that. And we train a model on English to Hindi, so that when we put in an English phrase, what we get out is the corresponding Hindi translation. That’s kind of like training from scratch. That would be, in my analogy, creating every line of code from scratch; we’re initializing all of the weights and the biases of our model, all the parameters of our model from scratch, from some random seed, or all starting at zero, or whatever that initialization is… But we’re using that English to Hindi corpus to train all of those parameters of the model from scratch…

Whereas now let’s say after we’ve done that, later on in our work we don’t want a model that is trained to translate English to Hindi, but we want English to Urdu, which is a related language. This means that we could do one of two things - we could either get another huge corpus of English to Urdu data and train from scratch again, or we could leverage the knowledge that we already created in that English to Hindi model. So we could take that model and all of the weights and parameters that we trained for English to Hindi, and then we could just slightly modify it or fine-tune it by re-training those on the new dataset, maybe a smaller amount of English to Urdu language.

[41:50] This has been widely used in NLP because in a lot of cases maybe you want to take a pre-trained model that’s very general, so it’s applied to maybe do translation for all domains, and you want to really fine-tune that for a specific domain of text, or of some content… So what you’ll do is you’ll fine-tune or slightly modify that on this new dataset.

So there’s kind of this initial pre-trained model, and then there’s the fine-tuning of that pre-trained model on a new dataset. So it could be on a new dataset, or you might fine-tune it by adding additional layers to it, as well.

Marc-Antoine Ruel: Well, it’s different, because the chip is much cheaper than the Pi. It has Wi-Fi, which I think it got announced before the Raspberry Pi 3 which had Wi-Fi. So it’s a different market.

The Pi is incredibly faster, but on the other hand you have to buy an SD card, while the chip already has 4 gigs of flash on board. Because of that, the total cost of the chip is much lower. And the fact that it has a battery connector included is also a plus. It’s very easy to run it on a Lithium battery, and it can charge to a Lithium battery, too. Because of that, the use cases are slightly different than the Pi. Up to an extent it’s closer to the Pi Zero, but still, the Pi Zero doesn’t have a battery charger, as far as I know. Actually, I just got one in the mail, but I didn’t have the time to open it yet.

So for embedded stuff – not embedded stuff, but for stuff to be carried on, it’s very nice. It’s something I really like a lot. One thing I wanted to backtrack is when I started the project on Periph I wasn’t sure actually if I were going to do it or not. Thorsten von Eicken, which I referenced earlier - he reached out to me in September or so of last year, and he wasn’t really contributing to embed. And then he looked at the way I was discussing the design and he was like, “I think you have a point here”, and it’s really worked. So basically I used his knowledge in this area to be able to have someone to discuss with until the project became public, and he did all of the code reviews, which really helped me to structure the project.

[32:03] I decided to make it private for a long time, because I really wanted to refactor the hell out of it. Basically, when you have a project and you have no users, you cannot break anyone, so that’s the best thing ever, because nobody’s complaining if they are not using it. But the problem is that eventually we want to have users, so the line there was when to make it public, versus keeping the liberty of breaking the library as much as I wanted.

Eventually, I got the pressure to actually release it, because eventually I just wanted to have something – people wanted to use it, but at the same time I still feel that it’s not… I feel right now that it’s not good enough in the design and I really want to change a lot of features. For example the SPI driver I’m not happy still with the current design of the interfaces.

Brian Ketelsen: I hate relying on those automated tools though, because they don’t bring any domain knowledge, and they don’t bring any logic or reason to the code review. I think they should be part of your CI system. You shouldn’t be able to just paste sloppy code into an editor and expect that to go to production, but there has to be a human looking at that code and saying “You know, it makes zero sense to allocate this variable 57 times, when you could have done it outside the loop.” And those are things that the linters don’t always catch.

Rod Vagg: That’s just right, and that brings up an important point, which I haven’t touched on at all which is the importance of leadership. It’s nice to have this idea that you’re gonna have people show up, you’re gonna have this emergent property of leadership, it’s just gonna emerge out of the mass of people doing things. That’s a nice idea and sometimes it works, but very often you still need leadership, and that leadership may be in the form of people putting in more effort than others.

[01:02:01.17] That’s what happens early on in a project - you’ve either got one person or a few people who are passionate enough about making this thing work, that they are willing to put in that much time to get it there; rarely do you have a lot of people doing that. Usually, there is only a small group or only one person, so that’s what leadership looks like initially.

As the project evolves you need somebody or some people to serve in that role of facilitating the community, and that comes down to the fact that not everyone is a leader and we ought to be fine with that, that not everyone wants to be a leader and not everyone has those natural skills to be a leader, and when you accept that then you see that there is a place for individuals to step up and just start being the grease in the wheels. And that can play out in really interesting ways; it can play out just by the fact that somebody is stepping up. Very often, other people will be looking for that person, and they’ll be waiting for it, and they step up and they might start to assert things, and other people involved in the project might say “Phew, finally somebody is here to take that burden.” And we can disagree with them, “Great, at least we’ve got someone to disagree with now. We don’t just have this mess of people that are too timid to really assert thing”, so having somebody stand up and start asserting can be a really valuable thing and people look forward to it.

The other way that it can manifest is simply in the respect that people get over time, and that’s how leadership can evolve in these projects. It evolves in open source in general; you build up this capital of respect by your contributions and by what you know and what people know that you know, and you see that in complex projects like Node. Node has a lot of different areas that are all very distinct and there are different levels of expertise in different areas that are required to understand them and nobody – there’s zero people in the Node Core project, amongst that group of people, that understand it all and that are experts in it all. Everybody is an expert in one area or a few areas, and nobody is an expert in it all.

And the way this kind of leadership evolves in that setting is that people build up the respect and the technical capital from other people that they know this area and that they are somebody to be listened to. One of the most obvious ways this plays out at Node is when you think about Crypto; it’s a really hard area for people to get across, very few people really understand it enough. We have a few people that are really well respected in that area, and we will generally defer to them, and often for even the most trivial things; we’ll say we need sign off from these people, or they need to be involved in this discussion in order for it to move forward, and then when those people in that small group - or it might be just one person even - they start proposing changes in their little area of expertise, they almost get a free pass because everyone looks at them as the leader in that area.

So that plays out really interestingly when you’ve got a complex enough project, but it also plays out in smaller projects when you’ve got simply somebody who has got obvious depth of technical knowledge and understanding about a project; they are generally recognized and they get to play that leadership role, as well.

Zeno Rocha: So that’s how the whole indexing of the web came from Bing as the data source for ChatGPT. So then - okay, now that’s different. How do I rank number one on Bing, versus Google? Which is something you would never really pay attention to. And then you have to start thinking about “How do I structure my content on my website?” Because people are asking questions to LLMs. So if they’re asking questions, then it’s a Q&A type of format. So then what we started doing was let’s just have more FAQs on every single page we have, and let’s turn our knowledge base to be more of a question and answer to feed the LLM. And then yeah, I’ve just started playing with llms.txt, which is like this protocol for you to just strip all the HTML and just have the content ready for LLMs to consume. So we did that as well. And man, just started going down that path. Using tools like Profound…

So there’s tryprofound.com, a tool that shows you all the traffic. This one is fascinating, by the way. So the way this works is they hook into your server, and then whenever the server gets a hit, they will look at the origin of the request, and then break it down between like “Okay, where is this request coming from?” And the reason why that works is because when you ask ChatGPT what is Resend’s pricing - for example, if you do that now, ChatGPT wasn’t trained in that data. So there’s no way that they know that. That’s different than if you ask ChatGPT, “Write me a poem.” They can do that using the trained data. But if you ask pricing for any product, they need to look at the web. So because they are able to search the web nowadays, you get a citation. And then when you get a citation, it’s basically them crawling your website, getting the information. So then you get that request. You see “Okay, ChatGPT went to my pricing page.” And then you can start looking at the breakdown between every model. Like, “Okay, Claude users, they actually go to this page. And ChatGPT users go here.” And it’s just fascinating. It’s a completely new way of looking into SEO, that’s for sure.