Mike Hartington: What you need to do is go on to Twitch, which is what all the cool kids do these days. Go on to Twitch and on the fly just recreate that talk. It’s like “Alright, we’re gonna go over some Vim. Hi, everyone…”

Amal Hussein: Honestly though, I think that’s like the fancy marketing message. I think this is gonna be a learning curve for all of us. I really do. Because I think it’s gonna be like “Oh, well if I don’t have to, why should I?” Don’t forget developers are – we are inherently lazy, and it’s a good thing; we conserve our mental energy. So you know, where do you draw the line for what you need to know and what you don’t need to know? I think that’s just where it gets murky, and I think that’s where we’re gonna have to learn the hard way, I think…

Miško Hevery: [35:55] Okay. So before I kind of explain how Qwik works, I think it’s useful to kind of go and do a parallel. So back in the day when VMware first came out, virtual machines, I was blown away with a particular thing about them, which is that on my host computer I can boot up let’s say Linux as my virtual machine, and the Linux boots up, goes through its boot-up process, and finally, at some point, I can log in. And once I’m logged in, I can, let’s say, open up a Chrome browser, and I can navigate to like Google Docs, for example, and I can start writing my document. And at some point, I can just save the virtual machine into a disk, and I can take that file and send it to a friend of mine, and that friend can then just open the file up and continue exactly where I left off…

Specifically, they don’t have to go through the boot-up process, the login process, the opening up of the Chrome, or Google Docs, or anything like that; they literally – bam, they’re in the final thing, and ready to go. And this is what I call resumable. And it is specifically how our current frameworks do not work, right? They can’t do that trick. Instead, what they do is they essentially - every time you need to navigate to a page, for all practical purposes they have to boot up. And this boot-up process, what we call hydration, is really the way the framework recovers all of the information about where the components are, where the listeners are, what is the data, and so on and so forth.

And we have some tricks… We can prevent the client application from doing fetch requests back to the server by prefetching, and pre-populating local caches that we can inline into our page… But at the end of the day, the application has to replay, it has to hydrate, it has to boot up, it has to go through all of these phases. And all of these phases kind of slow us down in terms of the startup. What it means in practice is that if somebody sends you a link on Twitter or somewhere and says “Look at these awesome shoes. You should go buy them.” You get the link, you click on it, and you see the shoes immediately, and then you’re like “Yeah, I want to buy it”, I add to shopping cart and nothing happens for several seconds, right? And at some point, you’re just like “You know what - I don’t really need the shoes.”

Miško Hevery: Okay. So before I kind of explain how Qwik works, I think it’s useful to kind of go and do a parallel. So back in the day when VMware first came out, virtual machines, I was blown away with a particular thing about them, which is that on my host computer I can boot up let’s say Linux as my virtual machine, and the Linux boots up, goes through its boot-up process, and finally, at some point, I can log in. And once I’m logged in, I can, let’s say, open up a Chrome browser, and I can navigate to like Google Docs, for example, and I can start writing my document. And at some point, I can just save the virtual machine into a disk, and I can take that file and send it to a friend of mine, and that friend can then just open the file up and continue exactly where I left off…

[08:17] Specifically, they don’t have to go through the boot-up process, the login process, the opening up of the Chrome, or Google Docs, or anything like that; they literally – bam, they’re in the final thing, and ready to go. And this is what I call resumable. And it is specifically how our current frameworks do not work, right? They can’t do that trick. Instead, what they do is they essentially - every time you need to navigate to a page, for all practical purposes they have to boot up. And this boot-up process, what we call hydration, is really the way the framework recovers all of the information about where the components are, where the listeners are, what is the data, and so on and so forth.

And we have some tricks… We can prevent the client application from doing fetch requests back to the server by prefetching, and pre-populating local caches that we can inline into our page… But at the end of the day, the application has to replay, it has to hydrate, it has to boot up, it has to go through all of these phases. And all of these phases kind of slow us down in terms of the startup. What it means in practice is that if somebody sends you a link on Twitter or somewhere and says “Look at these awesome shoes. You should go buy them.” You get the link, you click on it, and you see the shoes immediately, and then you’re like “Yeah, I want to buy it”, I add to shopping cart and nothing happens for several seconds, right? And at some point, you’re just like “You know what - I don’t really need the shoes.”

Johnny Boursiquot: Yeah, I totally agree. If there is interest, if you get to pick the work that you have a preference towards, I think you’ll probably enjoy that work more. But after doing this for a while, I’ve also seen the negative side of that. I’ve seen developers who take on a piece of a component or a piece of the architecture and they’re running with it, and if they don’t have somebody checking on them, they can sort of get into a rabbit hole, and they’re afraid of coming back out just to say “You know what, I am struggling. I do need some assistance. Maybe I bit on more than I could chew” or maybe “This feels like I’m doing way more work than is necessary.” There’s a certain level of humility that must also come with this sort of responsibility. The humility must be part of the responsibility. You have to be able to put some distance between yourself and the work, not have so much of an attachment to it… Whether it’s like “Oh, it’s mine. I’m the one who’s gonna work on this.” Or “Crap, I bit off more than I could chew and I can’t finish it, but I’m not gonna talk about it.”

You have to know enough about yourself and your tendencies to be able to step back and say “You know what, I need help.” Again, raising your hand, communicating with your team… And ideally, you’re in a team that’s not gonna judge you for that. They are willing to help you and pair with you and have a conversation with you hopefully about your high-level design if you have one… Ideally, those are the teams that function very well, and not just getting something in a JIRA email that says “Hey, you’ve now been assigned to this thing.”

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.

Mike Riley: [laughs] Right. It’s got a photo-sensor on it, so that if you have motion detection, you can do that type of thing. As a matter of fact, in one of the projects that I tie in the motion sensor along with another attachment that you can buy for the Pi, which is the Pi camera. That’s sold by the Raspberry Pi Foundation. There’s others you can buy too, with different kind of imaging quality. But the one that the Pi sells, the Pi Camera 2, is actually pretty good. It’s got both video and still frame capabilities built-in. And they’re fairly decent, even on low capabilities. So what I did in the book was show you how you can connect that motion sensor so that when there is motion detected, you can do a capture. And that capture - again, it could either be a video, or in my case, I just want it as a still image… And then you take that still image and you could email it as an attachment, but what I did was I tied it in the Discord API, so I could get an immediate notification along with the image, that shows me somebody just walked in the area that I was measuring. So if you wanted to protect your room, or you wanted to see if there’s anybody stopping by in front of your home, or any other place that you wanna see, if there’s motion detected… If you have a house pet that is looking to get into things - you could sit that up so that you would immediately get a notification on your phone or on your computer saying “This is what happened, this is what I saw”, and now you can act upon that. So that’s kind of a nice sensing capability.

Talking about the Hue, the reasons why I liked that so much for my lighting and electrical triggering needs is because they do have an open platform. In fact, there’s Hue libraries not just for Python, but for Go, for Rust, for Java… Pretty much any popular language that’s out there, Hue supports it either through third-party libraries that people have posted on GitHub… And it’s just really – again, it’s a nice, open platform to work with, so you’re able to interact with that Hue hub very simply. And I show in the book how it’s easy to use this very popular Hue library called pHue, for Python. It’s very comprehensive, very complete, and yet very easy to use, so that you can not only interrogate Hue to see what are the lights that are connected, including the names that you may have assigned them, but also to be able to trigger on auth connectivity… You can do dimming, you can change the color… So it really gives you a lot of flexibility. The deeper that you wanna get into, the level of sophistication is just really off the charts.

The other cool thing about all of this capability as you start to connect all these pieces together is the complexity that can grow out of a very simple project, and yet, because you were able to build it in stages, you’re very competent on knowing exactly what’s happening and all the dependencies that are connected to it. But at the same time, it’s acting almost - not like a sentient system, but certainly you would never be able to do something as sophisticated, with those level of triggers and actions and reactions if you didn’t have these capabilities and these systems in place.

So again, think about all the sensors that you can deploy, and all of the different feedback systems that you can enable. So based on all these sensors and whatever their values may be, you can act upon them and make them do things that you would not possibly be able to do, even with the very expensive automation platform that is custom-designed for those kinds of interactions, just because it’s such a unique use case that you can’t scale it to make it a commercial product. But for your own special needs, you can do some amazing things, and make it specifically tailor-made for exactly what you need to do, and that’s why I think that Py platform and all these automation capabilities and these sensors really make a lot of sense for the home enthusiasts.

Tom Pansino: Yes, you’re definitely correct in that. And I think a really good example of that, that Gunnar wanted me to mention, is we deliver that as part of our package. So when you sign up a team with us and you say, “I want to start a new team” or “I want to start a new domain”, you come to my team and make a request in our Slack channel, you give us the name of what you want to have created, in that bounded context, we’re delivering a set of resources in all of our cloud providers. So you say you want Fubar as your new domain or something like that - we’re going to go and create Amazon accounts, we’ll have a development account, a staging account to do load testing and other types of testing, and a production account. And so each of those accounts follows in line with Amazon best practices, and they have white papers written on why you should use accounts as your bounded context box to put things in… And it helps with what we refer to as the blast radius. I mean, if I have somebody who maybe makes a mistake, deletes a few too many things, it doesn’t tank the entire system. It’ll only hurt that one account. And separating out development and production we all know as a good idea as well.

But then in addition to those accounts, we also go a little bit further. And so as a piece of expertise, my team has some networking expertise in it, and creating networking is difficult in the cloud, many times… And so what we do is we deliver a VPC, as a package, as part of our account structure as well, so a networking stack. It has a VPC in it. It has one or more sub-NATs in it. Each of those subnets has a NAT gateway, so you can have private servers, private application servers behind the NAT gateway for extra security; it has an internet gateway for connectivity. We teach people about how to use security groups. They’re set up with multiple availability zones for redundancy, so that people don’t have to think about that, and it’s just like, “Yeah, you have a server that’s in the cloud, that’s running? Great. Bring it to our VPC, plug it in with these subnets in the Amazon UI and you’re off and running”, and you don’t have to think about networking anymore, other than if it breaks, which we have health checks for that.

[16:37] So on our end, we try to run it as a service to where there’s nothing that the customer has to really spend a lot of time thinking about. That’s kind of the goal on our end; as you said, it’s almost a team API, not just a code API, and that’s where I think the Topologies book refers to it as this team API, of what do I need to do and what do you need to do to be successful.

Mireille Reece, PsyD: Right? But think of all these other things that distract you away from the pain that you’re feeling. So people come to me out of this place of pain, of like, “I don’t know what to do. I’ve gotten to the end of my rope. I’ve exhausted all the skills, strategies, things I’ve known,” and usually even tried other things that haven’t provided the dividends that they desire. So it’s like, “Here’s the last-ditch effort.” But this is also why I tell people when I start working with them that my goal is ultimately to work myself out of a job… Because some people will think, “Well, they just want you to keep coming,” and it’s like, no, no, no, no, no. If you’re actually doing the work, which ironically involves pain, the goal is that you would have less pain because you’ve been able to work through the things that were causing the pain. So you feel different, i.e. happier, more content, more fulfilled, more connected.

So one of my favorite takeaways or things from this book is really– we talk so much about application; just knowledge in and of itself isn’t enough, but rather, what do you need to do in terms of action. The way in which the author writes this is so good for just like little nuggets, not just, “Hey, here’s the little data or explanation relative to why you’re getting distracted,” but one, here’s a mental framework to help you keep it in picture or in mind as you’re trying to do differently, and here’s a little nugget that you could do differently. So you don’t necessarily even have to read the book in one fell swoop. You could just sit down and read one section or one part, as the book is broken up into five different parts. And then one really cool thing that we’ll come back to at the end is that he includes actually a book discussion at the end. So if you wanted to actually get a crew of people, i.e. get connected differently and have conversations around how you could implement some of these things, it’s already templated for you.

Adam Stacoviak: The book I wanna add to it is Essentialism, by Greg McKeown. There’s a chapter in that book that I don’t get right, but it reminds me of its importance. I don’t recall the chapter number, but the chapter name is “Protect the asset.” It’s essentially about protecting your sleep, protecting your health… Because you can’t be you unless you’re you; and you’re not you unless you’ve got your mind, you’re not you unless you have your mental health, your body… And essentialism kind of reminds you – I think even this pandemic has been a resurgence of finding out what’s essential to you. What’s essential to you? And that’s what it is; it’s not minimalism, it’s not a tribe, it’s not some sort of religion… It’s “What is essential in your life?” The vital few, versus the trivial many. What do you need to work on right now? What really matters to you?

That chapter, “Protect the asset” to me was mind-blowing. It seems so simple, “Protect the asset”, protect your sleep, protect your health, but so often do we trade our health, our mental freedoms for other things, for whatever reason.

Emily Robinson: Yeah. I mean, this is something that varies by company, of course, how it looks… What you need to do in your first couple of months at a startup where you’re the first data scientist is quite different if you’re joining a mature and functioning team. With that being said, I think there’s a couple of principles that really apply to any type of new role… And a big one there is really trying to learn as much as you can and not being afraid to ask questions. That doesn’t mean necessarily you should ask a question that you could easily google, like “What is the difference between a vector and a list in R, but really don’t be afraid of asking questions, trying to understand “Where does something live? Where could I find docs on past projects? Why do we do things this way? What Slack channels should I be in? What does this data mean?” and so on and so forth. To ask those really with a sense of curiosity and not a sense of, for example – not quite entitlement, but like “Why do we do it this way, instead of this?”, like clearly superior way that I learned in school. You don’t wanna come off immediately as like “Oh wow, I can’t believe you all are idiots. I can’t believe you’re doing it this way, and I’m so glad I’m here to fix it all”, and really try to keep an open mind… Which doesn’t mean, of course, that everything you’re doing is perfect.

[39:50] Ideally, you came in and you are hired because you have a lot to contribute… And in those first couple months really focusing on learning the most and trying to set yourself up to be productive in the long-term, and not worried too much about “Oh wow, I really immediately have to start delivering, or they’re gonna wonder why they hired me.” Because I think if that was truly the case, that’s usually a sign of not a very good and supportive company, if they’re expecting you to immediately start delivering reports and other things.

Of course, you can start doing small stuff, but they recognize it takes time to ramp up, and you don’t wanna become too focus immediately on the short-term, rather than for example spending a day or two making sure – you know, building some internal functions, for example if you’re the first data scientist, to make it a lot easier for you to load data, which is something you’re gonna be doing every day from now on… And by saving ten minutes every time you do that, it’s really gonna pay back in the long-term.

Mark Bates: Yeah. I don’t think it’s ready to be version 1 yet. In that particular case, I think there’s still a lot of work that needs to be done in a bunch of places; not just the library APIs, but just some of the features and compatibility with other systems that we want to make sure are in there. We’re still trying to figure that out. Google App Engine was a big one, but that’s kind of gone away, so I think we just need more of a how-to guide to check that one off the list…

But you know, the way I build my APIs - and I was having this conversation with somebody yesterday on Slack - is I actually think the best APIs are those consumed by the person writing them just constantly. They said to me “Oh, somebody who dogfoods their own stuff as much as you do…” and I’m like “Well, I wrote it because I needed it, so yeah, I’m gonna dogfood it…” And by doing that, what happens is you start working away those rough edges.

[11:57] I think what Mat said - he started with something really small, and that’s usually how I do it. I kind of do a combination of what JBD does and what Mat was talking about, which is I often just kind of play around, scrappy files, and hack away at something until I feel “Okay, I understand the domain now.”

A good example of that, a couple weeks I used JBD’s Mini package to write some transport controls for logic, and it was a lot of hacking around just trying to figure out how to make it work, how to talk to logic… And once I do that, then I can refactor that into something that’s a lot more user-friendly, serviceable, testable, that sort of stuff. I don’t ever go straight for “I’m gonna design the perfect API”, because it never works. I don’t think I’ve ever sat down and designed a perfect API.

What I try to do is, like I said, I try to understand the problem domain, know the problem I’m trying to solve, and then I try to write APIs that hit the 80% use case. So you can do 80% of what you need to do in just a couple lines of code. But I like to make sure that you have all the underlying support to do that other 20%, but you’re gonna have to wire it up manually.

What I find is when I’m dogfooding, I’ll have that 80%, but I’ll see another thing now that becomes a thorn in my side, because it’s not as smooth a process, and that’s when I wrap that in an API, to make that a one or two-liner. And you know, I just keep sanding those rough edges off.

Bryan Liles: Well, I look at it like Double Dutch. Have you ever double dutched before? It’s really hard, actually, if you look at it. There’s two ropes, they’re moving in two different directions, and you always see the person who’s getting ready to go next; they’re always rocking back and forth, rocking back and forth. And then they just jump in. That’s generally how I approach almost everything.

I solved problems that I’ve heard afterwards from PhD statisticians “You shouldn’t have been able to do that without that knowledge.” What I’ve learned from that is you have to be pretty naive in the way that you think about yourself. There’s nothing you can’t do. I live that life. I could go out and I could beat Usain Bolts, but until I get on the track and actually beat him, in my mind I’m actually winning.

It doesn’t work for everything, but for computer things, it allows you to at least get the confidence to go out and figure out what you need to do, rather than be overwhelmed with all the complexities.

Jatin Ramanathan: So I have a somewhat different take than Misko, maybe. First of all, I’m really glad that Misko and Qwik have given us the vocabulary to talk about stuff like this… Because before the word resumability, I would struggle to even explain what’s going on. And my hands are waving around, and I’m trying to explain how the event handlers are attached, and… Yeah, which is failing horribly. Everyone’s like “I don’t understand, why does it matter?” And it’s true, it doesn’t matter for many, many applications… Because you can just have your users wait a second, right? Maybe they’re gonna spend a lot of time on your site, like an hour or something. And so if it takes another second for it to hydrate, what’s the problem? But every once in a while we’ll have this experience on the internet where you’re rage-clicking a button and nothing’s happening. Like, you got to the site, you could see the button, you are clicking, and nothing’s happening. Why isn’t it working? And then “Oh, they’re loading the JavaScript and hydrating the page. There’s no event handler, that’s why nothing’s happening.”

So the simplest kind of way to understand resumability would be “It’s fine. Keep doing hydration”, like your framework is doing right now. But think about what you can do not drop events after server-side-rendered content is visible, and you’re about to hydrate the page. And just try to understand what will you need to do if you had this desire, this goal that you shouldn’t drop any events at all. And pulling on that thread kind of starts taking you closer and closer towards resumability. Even if you’re thinking you’re just going to do hydration, like React, or Vue, or any framework today that does hydration, you could try to add resumability by trying to save those events.

Yaron Singer: Yeah, there’s an inevitable trade-off, as you were saying. I’m of the opinion that the goal of any technology is to basically support humans, not replace them. On the one hand, we wanna support human decision-making; wherever it can help automate and de-bias human decision-making, we wanna support that, and not replace that. But at the same time, we want to make sure that we’re now replacing human judgment.

I think that the challenge that we have in our world - I don’t know that we will have that choice… Meaning that we don’t have a person sitting in every critical decision junction, and making that critical human judgment. It doesn’t scale. And that’s the biggest challenge that we have.

So with that in mind, what we need to do is we need to make sure that – it’s never gonna be perfect, but we need to know that we’re making every possible effort to make sure that it is as safe and risk-free as much as possible.

David Wickes: [19:44] I agree with everything Chris has said… I just would like to put out a word of warning in terms of following the process. Because we agree that following the process is important - Red-Green-Refactor. This can be terrible; this can be a terrible mistake sometimes… Because if you follow that process like it’s a magic algorithm to spit code out, you’re basically “I write my tests like that. It’s done. I write my code. Next. Refactor. I don’t know, I’ll rename a few methods… Write another test. Write some more code. Refactor. Maybe I’ll change the names of a few more methods” It doesn’t work. Rich Hickey has a great line about TDD. I mean, I feel he misunderstands TDD, don’t get me wrong, but he says it’s basically like driving by hitting the guard rails. “Oh, that broke. Oh, that broke. Oh, that broke. I don’t really know what I’m doing, but I’m writing tests, so it must be working, and I must be making progress.” This is wrong. If you’re doing TDD like that, you’re missing the trick. I’ll put it like that. I don’t think you’re doing TDD very well if you’re doing it like that.

You should be looking at each stage and thinking, carefully, “What’s going on here?” When you’re writing that failing test, if the error message could be better. We talked about that a lot. But the other thing is “What is this like now, when I’m writing this failing test?” Now I’ve got all these other tests in my wonderful test suite; is it easy to write this next test? Is it hard? Am I now having to do some weird logical jumpy bits around. Am I having endless helper methods in my test suite in order to get this test written? If you are, don’t do that. Back out. You need now to go back to refactoring. I know, we just went from writing a new test back to refactoring, but this is fine. You might need to do this sometimes, refactoring your code, to make that next test easier to write.

And this idea that people have is something I hear when people don’t like TDD and it’s okay not to like TDD. But it’s usually a thing like “It doesn’t lead to good design. It just leads to chaos, you end up with all these tightly-coupled tests everywhere…”, and it’s like, dude, this is not gonna drive things for you. It’s not a replacement of thinking and common sense; it’s a tool, you’ve gotta use it. So that’s that off my chest… [laughs]

Matt E. Patterson: I mean, it seems to me that as long as you’re running on any of the modern browsers, there doesn’t seem to be significant problems with that. Enough so that the Basecamp guys have doubled down on it with Hotwire. Now, they even have, as I mentioned before, a fallback in there… So if you’re really concerned about that sort of thing, there’s no reason you couldn’t also implement a fallback to Ajax in the case where you couldn’t get some data. And I think some of that comes down to what you’re app does, what you need it to do, what you care about deeply. Do you wanna build your stock trading app using a WebSocket? Well, you probably wanna have a fallback there to ensure that a trade that’s trying to go through in a millisecond time actually gets through in case something flakes out.

That said, the apps that I’ve built so far with this approach - I’ve had almost no issues in that respect. With modern browsers they work just fine, and if anything, most of the time the issue is something I created myself with bad code…

Lynne Tye: Well, it’s funny now, because as a developer, I would hate for someone to just show up and be like “Hey, hey! Whatever you’re doing - not important. I’m the most important thing. Do what I need you to do.” But that’s what I did.

And then yeah, someone just was like “Oh, I’ll do it.” And they in five minutes they were like “Oh, simple.” It was an issue with the logic, and they just fixed it, in one or two lines of code. And to me, I was like “Wow, this is straight up magic.” It just seemed so powerful. And I think that was the first time it really planted a seed in my mind that coding is wizardry, and I wanted to be able to wield that power, too… And it doesn’t matter how many one-on-one meetings I did, that had so much impact. Instantly, my phone started blowing up, and everyone was saying “Thank you”, and it was just over. So that planted a seed, so I really appreciate that exposure from Homejoy.

After I quit Homejoy I did a little bit more soul-searching, a bit more traveling, but then I decided that I wanted to learn how to code, so that’s kind of how that – that was a really long answer for how I started learning to code.

Then I did a bootcamp, quit that… [laughs] Learned a little on my own, freelanced for a couple of years, and then around March 2017 I sat down to look for full-time roles, and that’s when I realized that the job search was not fun… It was just so broken to me. It just made no sense that I wanna work for an early-stage startup, which I already know not many people want to do; it’s a very weird personality, to want to work at this risky, unknown entity, that could potentially blow up in any number of months… A good or a bad blow-up, I guess.

Jack Shanahan: I think so strongly about this idea of human machine teaming or human systems integration, that if we don’t get this right, we’re in trouble. And what I mean by that is, there are people have been writing about human-machine teaming in some form for 50 years. No different in terms of the concept of “How do you get the most out of human machines?” But to me, we’re at a period where it is changing. And it’s changing because the machines are going to be so much smarter than we’re used to talking about, that it will be a different view of human machine teaming than we’re used to. So I think there’s a whole new research field. There are already people working on this, and I’m amazed at some of the work that’s being done. But we just don’t know how good some of these technologies are going to be.

Let’s just take the example - very brief, the example of sort of ChatGPT, or the equivalent. There’s this idea of prompt engineering. I look at that as almost like the elevator operator in the ’30s or ‘40s, whenever it was, and it goes away eventually, because people get comfortable with it. But they’re not as comfortable with it today. You need help figuring out what that interface looks like.

But the other thing I’d say - and this is where I come back to - I really do believe there will be situations… I call this the bell curve of military operations. Some cases, you really do want that human making that final decision. Maybe to launch nuclear weapons as the President of the United States, and nobody but the President of the United States. On the other end, you need the machine to do what the machine does best. There is no time to get in the way. Everything else in between - I don’t know what that is. 80%, 90% is human machine optimized for both. That Centaur idea. And that we need a lot more work working through. And here’s the example I would give from my time in the flying world… There were a lot of times the machine did not operate as intended. The human was there to make sure that everything went fine with the mission. “Oh, that broke again. We’re going to have to pull that circuit breaker…” I started in the F4. Circuit breakers popped all the time. [unintelligible 00:37:12.27] hydraulic fluid out the backend, whatever. So the human would have to make up for a lot of the machine’s mistakes. I’m not sure that’s going to be a luxury in the future. You’re going to have to let the machine do what the machine does, and the human do what the machine does very well. What do humans do well? They do reasoning. They do inductive reasoning. They do deductive reasoning, they do inductive reasoning. They put things in context, they deal with other human emotions. Machines don’t deal with emotions, they don’t understand emotions, and I’m not sure, despite what some people claim, they ever will.

So what does that look like? I think there’s a lot that has to be done in this area in experimentation. Play around with it, see what works. Because if you don’t get it right - and there’s a couple of examples where it’s went dramatically badly, and I think the 737 max is one of those examples. “Well, we’re gonna put this software in. Trust us, you don’t need to be retrained as a pilot on this. Just listen to what it says in the cockpit.” That was wrong, and it has proven that it was dramatically the wrong thing to do.

[00:38:11.12] So I think this is an area that needs a lot more explanation. There are people writing about this, and really good writing, in various places… But we have to figure out how to get this part right. Because the machines are going to be smart enough that they have to be allowed to sort of run when they should run.

Jerod Santo: I love this for two reasons. One: we had Oz on the show a few years back and I am convinced that he’s a legitematly good teacher of this stuff. Two: as it says on the website, there are so many resources out there these days, but some are better than others and you usually don’t want another listicle of them. What you do need is answers to these questions: why subjects should I learn, and why? And what is the best book or video lecture series for each subject?

teachyourselfcs.com is their attempt to definitevely answer these questions. The TL;DR; of the guide is the following: “Study all nine subjects listed below, in roughly the presented order, using either the suggested textbook or video lecture series, but ideally both. Aim for 100-200 hours of study of each topic, then revisit favorites throughout your career”

Bill Kennedy: Yeah, it’s mind blowing to me, Chris; mind blowing. I cannot – I’m telling you right now, the thought of me writing a test first, for an API that doesn’t exist yet, because I haven’t really figured out what I need it to do is mind blowing.

Gerhard Lazu: Why not? Because I think you should. I think if you’re not doing that, something somewhere is not as good as it should be. If you have that full confidence in what you write and what you build, and you make small changes, and you keep constantly shipping them out into production… So what is the smallest change that I can make which moves this in the right direction? Whether it’s a feature, whether it’s a fix, whatever it is. It doesn’t really matter. You’re trying to learn something. How can I get it out there as soon as possible, so that I see that it actually works? Because it’s the combination of all the things, which maybe it results in it not working. And the sooner you find that out, the smaller the change, the better you chances for finding the improvement. What would make this better? “Hm… It didn’t work the way I thought it did. The tests are green, everything worked, but it still doesn’t behave correctly. So what am I missing? What do I need to learn here?” You can only do that in production. Anything else is like a pretend. You know, staging… Everything’s fine, everything’s fine… And the longer you wait until you get into production, the more difficult it is for you to realize “Well, where is the delta?” Because there are so many steps.

But anyways, that’s my thinking… And I welcome a different opinion, because I want to learn why that is. I want to figure out what the delta is, what am I missing.

Evan Kaplan: So there are five core values to the company - and by the way, this wasn’t something… It’s not a dorm room poster; we didn’t put it up and say “These are them.” When we had the first 20-25 employees we started with a process that said “What do you love about being here now, and what do you feel like you need to be successful?” We got all that input, we had small groups, and then we post-processed that, and that became the values. They won’t change, they’re part of the fundament of who we are. We’re not arrogant, we’re humble, we face up, we learn quickly, all that sort of stuff. We value – the second is “Failure is okay. I want you to fail fast and do it often.” I’m not quoting these exactly.

The third is around really diversity. We respect who you are, wherever you’re coming from. We wanna be inclusive and this to be a safe place for people to work. The fourth is we get stuff done. We just get stuff done, because we get a fair amount of satisfaction from getting stuff done… And lastly, it’s that commitment to open source. It’s part of every interview process that we’re doing for folks…

In my mind, and in the rest of my team’s - we wanna be held accountable for it, and people held me accountable before, when they didn’t think I was acting in that way. And I offer that up pretty continually - I wanna be held accountable that I am true to those values.

Johnny Boursiquot: Well, I wanna hang on to that question, because I think we should level-set a little bit around what it means to produce documentation. So a few years ago, maybe 3 or 4 years, I saw this talk from a person by the name [unintelligible 00:40:40.25] given at PyCon Australia in 2017. And in that talk, Daniel proceeds to break down – I experienced the talk, sort of a wiping away of some crud I had in my eyes around the different kinds of documentation… Because I was conflating different kinds of documentation together, so he clarified, he washed away the mud from my eyes from me, so I could see the different kinds of documentation and how they fit together.

So you have tutorials - those are learning-oriented. You’re sitting down, you’re going through the tutorial, you’re reading something, you’re trying it out, so you’re going back and forth, you read, you do, you read, you do… They’re learning-oriented.

Then you have your how-to guides. Your how-to guides are problem-oriented. You want to solve problem X - you go to the how-to guide, you find problem X, and it tells you step by step what it is that you need to do; the how-to. “This is how you solve this problem.”

And then you have your explanations. Those are the understanding-oriented. Those are the things that you are more likely to see narratives around, stories around. Those are the conference talks, if they’ve done well. You’re able to not touch on a bunch of low-level esoteric minutiae, but really paint a broad picture for you, “This is what I’m talking about. This is the problem we’re solving, this is what I’m presenting.” That’s your explanation.

And then you have your reference. This is exactly where the GoDoc sits. It’s a reference. It’s for look-up. You know exactly what you’re looking for. You already know in your mind, “Yes, I think I’ve seen a function or a package in Go that does this.” Then you go to GoDoc and you look for it. You’re doing a look-up. That’s a dictionary. That’s what it is.

So all of these things, no one is better than the other. It’s all working together, and it creates a documentation ecosystem, a well-documented ecosystem.

To circle back around to your question, Jerod, what’s the right angle here? There’s lots of ways you can go about this whole documentation or attempting to solve Eric Miller’s problem… I’m sure he has access to the tutorials, like we all do… There’s some how-to guides [unintelligible 00:43:04.02] here and there… I would say we can do better with the explanation aspect of things, which I suspect really that’s what’s lacking for him… And obviously, we have the reference, which is golden. It serves its purpose. Knowing what we know of documentation and what I’ve just explained here, how could we try to solve Eric’s problem?

Hisham Muhammad: But that was a huge contribution to the project. That one message. Sometimes it’s all you need to do. And this is what I see a lot… As you said, sometimes there’s a lot of drama on GitHub, or on the internet at large… But generally, my relationship with open source, with free software, those communities has been positive, in that sense. I feel this thread is actually representative of my life with free and open source software, really. If I fly out for a conference, whether it was FISL (International Free Software Forum) that happened here in my neighborhood, in Porto Alegre, Southern Brazil, every year, where people from all over Latin America would fly here… Or in Brussels, at FOSDEM, where the European free software folks get together… It’s always generally positive. We see a lot of – sometimes the drama gets over-amplified on the internet… But when it comes to people meeting face-to-face - and I know that meeting face-to-face is not something available to everybody, so we have to be mindful of that. Whenever we’ve got the chance to meet people face-to-face, or even over a video call, as I’m talking to you folks - that’s a way of having a more personal connection - we have to carry that to our online written communications and interactions.

[01:03:18.04] I feel that – I kind of have sort of a pet peeve with the whole code review culture and what it is… I notice that even the style of writing that people use when they’re doing code reviews is kind of different when they’re sending a message on Slack, or something. When I noticed that, I decided to become more consciously informal, and go like “Hey, it looks like something like this is missing etc. *emoji*” Not in a forced way, but - okay, I’m gonna talk to this person the way I would talk to them in-person, rather than “This seems inappropriate at line 375.” You feel like the schoolmaster, grading someone’s PR, like “This is acceptable. No, this is unacceptable.” So I think it boils down to this as well, how we communicate and how we interact with people. It makes a difference.

As you said, the way the conversation starts is the way the conversation flows. To that - yeah, for sure. That was super-important.

Chris Benson: It’s gonna be both, but what you have to start doing is you have to connect on the assumption that your operations, whether internal or external, are government by some (essentially) policies internally. You really have to connect the principles to the policies that you have, because those policies are representing the reality, or at least an ideal reality the organization is trying to achieve. And so until you can map principles to the policies that you already have in place and figure out if you have gaps and need to create new policies or change existing policies, that’s the first step - saying “I understand how the principles that we’ve said identify our values map out to the policies that govern our operations and our functions.”

So that’s really the first step. And then you’ll follow that up with “How do we know that we are in compliance then? What’s the mechanism and how do we govern that? If something goes awry with the way that we’re thinking about this, how does our organization handle that and process that?” Like you would have in anything having not to do with AI ethics - if you have something in your operations that is not compliant with your expectation, how do you handle that? You need that for this as well, and then you need to connect that to the people that are doing the actual work. It needs to fit into the workflow, and it needs to fit into the tooling… And if it doesn’t, or if that’s not an easy thing to do, then you need to figure out what that delta is and figure out “Do I need new tools? Do I need to adjust existing tools?” which has a lot of variability based on “Are they vendor tools that we’re paying for and we’re limited to the features that the vendor offers us? Is it stuff that we’ve written for ourselves? How do we know that and how do we get these to filter in at the workflow level in terms of being productive?”

It’s quite a long process, actually. I would say it starts with principles, and that’s what most people think of now… But once you’ve done your principles, you’ve basically just gotten to the starting line.

Heather Meeker: Well, I’d say that something is open source or it’s not open source. For instance, fair source is not open source, and nobody would have claimed that it was. The hybrid model - maybe you call it source available, although that’s a pretty awkward term. Fundamentally, what makes something proprietary rather than open source is any kind of license restriction. So something like fair source that says, “You can use it up to X number of users and then you have to pay us”, that is actually a user restriction of a sort. It’s a light one, it’s not like the user restriction that you would get in your basic commercial proprietary license which would say something more like “You can use this for a hundred users. Period. If you go over that, you’re a copyright infringer.” That’s more draconian and that’s the quintessential proprietary license model. But nevertheless, something like fair source is actually license limitation, and so it can’t be open source, because the open source definition - the most important thing about it is “no license restrictions.”

[48:00] Maybe this is obvious, but people who manage software in organizations spend an extraordinary amount of time managing license restrictions. You can go to entire conferences on how to figure out whether you’ve exceeded your thousand-user limit and so forth, and there’s also technology to monitor it and all this kind of thing. Well, open source liberates you from all of that. That is one reason why people love open source - you don’t have to manage license restrictions.

Now, if you’re an author and you wanna release your code, you can choose open source or you can choose something else. If you choose something else, it’s pretty much designer; you get to pick whatever you want. Example - fair source; pick a set of terms that you think are fair, and that will make sure that people can use the software, but that if they’re making a huge amount of productive use out of it, that you get some kind of financial benefit from it.

I’m a lawyer in private practice, so my job is to serve my client’s interest, and if they wanna pick a proprietary model, that’s their right to do it, and I will help them do it. That’s my job. My main goal in doing that is making sure that they’re calling it open source when it’s not, because that would actually be problematic.

Then there are other sort of hybrid models where it’s like, “Well, something is released under a proprietary license, but it transforms to open source after a certain amount of time.” Okay, that’s definitely a hybrid model, but it changes from one to the other very clearly. One thing I would point out is that you don’t necessarily need a license to do that. What you can do is release something in proprietary form and then later release it under an open source license. Now people have written things where that happens automatically after a certain amount of time.

If you take a larger view and say, okay, all you’re really doing there is releasing something under a proprietary license and then later releasing it under open source terms, that’s a time-honored tradition in the technology business, where companies will put a lot of development into code and they will give it sort of on a first-look basis to paying customers, and then they will release it open source to the world for free. I don’t think there’s anything nefarious about that; they’re trying to recoup some of their cost, or get some financial benefit for the development effort they’ve put into it. Of course, I don’t think there’s anything wrong about that, as long as they’re clear about what they’re doing.

There are infinite variations, and when you’re in the proprietary area, not open source, as I mentioned as we were discussing previously, by definition there are infinite variations, because there’s no standardization in proprietary licensing. I’m fine about all these models as long as people are clear about what they’re doing and don’t leave the whole world scratching their heads about what is going on.

Daniel Whitenack: I think this is something we’ve highlighted on the show before, but people sort of have this perception that “Oh, we’ve got a bunch of documents in a file store. We’ve got a big database.” We should be able to do AI or do machine learning with that data. And the situation is definitely more complex than that. So I would say that there’s really two things maybe that people need to have in their mind. One is the type of task that you’re wanting to do, which maybe is also related to the type of model that you’ll use. And also, what is the state of the structure of the data that you have?

[00:12:05.15] Let’s give an example. So let’s say that you want to do object detection, which is the task of taking in an image and detecting what objects are in that image. So that’s a computer vision task. You usually require some type of convolutional neural network… And some of this you could search through and find the type of task that you are trying to do, and then the typical model that is used to do that. And you might find - oh, these typical models that are used for object detection usually need thousands and maybe millions of images to train on. So that may trigger in your mind, “Well, first of all, do I have enough imagery to train that model?” If you do have enough data to train the type of model that you’re interested in, then maybe you do that. But oftentimes, what people need to do is fine-tune a model, not train a model from scratch.

So that would be taking a model that already exists, maybe it’s posted on Hugging Face in a repo that is already trained for some type of task related to what you’re doing, so maybe a similar object detection task. And then you continue the training on from that point with your small amount of data.

Now, the second piece to that is, like I mentioned, how structured or unstructured your data is. So if I just have a bunch of images in a file store, that really doesn’t do me any good for that object detection task, because they’re not pre-labeled with labels that I would be able to use to further train one of those models. So another relevant thing here is, is your data unstructured or unlabeled, or structured or labeled? And in the case of training a supervised type model, which is a model that requires some labels to be trained, like an object detection model, or sentiment analysis, or machine translation maybe, then you need those labels in order to further train your model.

So just to kind of recap what I just said there, there was the element of determining what task and what kind of model is needed, and how that maps to your data, and then whether you have enough data or not enough data for pre-training or just fine-tuning. And then finally, if you have labeled or unlabeled data, or structured or unstructured data.

Angelica Hill: I mean, as you were talking, I think what came to mind for me is do you think that those growing pains are related to the growth of the Go community? I mean, what I’m thinking of is just logistically, when the language was small, there were less people in the community, so it was easier to hear those voices. Whereas now, we’re a spooling, a huge global community… I would assume it’s – well, in fact, I would know it must be harder to keep your pulse on that community, especially when, as you noted, Kris, there are people who just, they sit, they use Go, they’re not going to engage in Gopher Slack, the Reddit… There are a number of people who want to be active voices in the community, but there are so many others that are not engaging in those conversations, but are really active Go users.

So I wonder if part of the issue, or part of the disconnect is somewhat inevitable, given one team, one leader, say - I know we’re talking about kind of being [unintelligible 00:24:09.27] on the Go team, it must be really hard to keep your pulse on that full community, and making sure everyone’s happy. And I would venture that it’s impossible to make everyone happy. I’m just intrigued.

[00:24:24.19] And then also just going back to the title of “tech lead”, you are the technical lead. That does that not then imply that you are accountable for the technology, its resilience. For me, it feels - and maybe this is just my personal view - more like it’s, I don’t know, a product manager, or someone else’s role; everyone on the team 100% should have that pulse on the broader community, but I just wonder, just thinking on the granular… I have always seen the role of tech lead to be leading the technology. I think they should be, and to be a great tech lead I think you need to have your pulse on the community… But I wonder whether ascribing that to the lead - I think it’s a group effort. I think it’s a community effort. The Go team in general - that should be part of what they do, and I think they do… Looking at the Slack, they engage in conferences, they look at the issue tracker… But also we as a community, as individuals can just encourage people who care deeply, but maybe aren’t looking at decisions, or being part of the conversation. I don’t know, I’m just speaking aloud here.

Johnny Boursiquot: I mean, the first I – in my workflow for validating things, which includes looking at pkg.go.dev, and that metadata, whatever it is, if I dig sufficiently enough, one of the things that I do when I’m looking at repositories for some dependency that my dependency, or however many deep I have to go, if I just do a quick search for an HTTP package in the repository, if I find some… [laughs] Then I’m going to be very interested in this package. This thing is supposed to be, I don’t know, flipping characters backwards, or something… Why is the HTTP package in here? What do you need? You kind of have to be critical. “This package is supposed to do this thing, very specific thing. Why is it doing network calls? What’s going on?” Things like that, that should be obvious smells that you need to investigate. And these are what I’m talking about. We can’t catch everything. And whatever our processes are that we think “Oh yeah, we go through umpteen different hoops we make people jump through, so we avoided vulnerabilities”, security is a game of mitigation and sort of safeguards, and it’s not something you can 100% sort of do. So part of that mitigation is you as a developer, you’re kind of the first line of defense here. And sort of being critical of these things. I’m importing this package, it’s supposed to do this… Why is it doing that?