Daniel Whitenack: It’s not enough, yeah. Don’t give our listeners ideas, because I don’t know if I could do a daily show… [laughter] But it is a lot. And I think – so I’m looking back previous at our episode, and last time we talked about sort of the easiest way to create ML apps. That was part of how the conversation was framed. And I know just from working with you, and talking with you as friends, that a lot has changed, and you’ve seen some things within how people are deploying machine learning AI systems that now Baseten is really focused on. Could you give us kind of like the high-level view of Baseten and the type of problem, the type of solution that you’re offering?

Gregory Richardson: Ismael touched a little bit, he kind of grazed over LLMs, and I’m glad you only grazed over it because of what I’m about to say. We think LLMs, as good as they are, and they have some excellent use cases and value, I think they contribute to a lot of the noise and the hype machines that we hear in the industry right now. I’ll speak specifically for cybersecurity. I am not yet convinced of the utility, the usefulness of an LLM, particularly for its natural language ability, ability to process things via natural language… I’m not sure that that was the problem we had. I speak to psych analysts, and chief information security officers literally on a daily basis. That’s my job. I can’t remember in the last 30 years doing this, that a group of operators, SOC analysts etc. have told me, “You know what would be great, Greg? We don’t know how to extract the data from our tools. If we could only say that in natural language, that would really help.”

That’s not the problem. The people that are doing these jobs in the SOCs etc. are very adept at their tools. They don’t have the problem communicating with the tools, and writing a parsing command, or a query or whatever, to extract the data. That’s not the issue. There’s other things that AI and machine learning can help with. Classification is a big one. Ismael has already referred to prediction. I think that’s a very, very big one, that is underutilized today.

But classification - how do we classify not only files and hashes, but behaviors, indicators of attack, indicators of compromise? How are we able to classify these three things that are connected together, or in the case of a cyber attack these 50 things, these 50 behaviors or indicators we find - how can we pull them all together and say “Listen, these all belong together. These 10 things that we’ve found on your network and these 15 things that we’ve found on your endpoint, and these 12 other things that we’ve found simultaneously, in the same temporal window in your cloud environment, they all belong together and they’re all part of one attack.” That classification process - I think that’s somewhere where AI can help, because that’s where the gap is. Taking the ton of data that comes in, that swamps our security operation centers with alert fatigue, parsing through that to “make sense of it” and kind of narrow it down to a few cases. And when I say few, that few may be thousands still, but it’s an order of magnitude or more drop from the tens or hundreds of thousands of events that you get. If you can drop that down to a significantly smaller amount of cases and then tackle those cases, that’s one of the problems that I see AI solving in cybersecurity extremely well.

Steve Jobs: One of the things you learn when you start building factories is that warehouses are really bad, right? Warehouses are bad, because you tend to put things in them. And inventory is really bad; inventory is really bad because if it’s defective, you don’t find out about it for a while, and you don’t close the quality feedback loop with a vendor, and correct the problem till they’ve made a zillion of them. What you want to do is find a problem, the first one that comes in the door, and stop them from making more until you fix the problem. So warehouses also cost money, because you put all this stuff in them, and the stuff - you have to go borrow money from the bank or use money that could be used in a more productive purpose. So warehouses are bad, and you want to go to JIT; I’m sure you’ve studied this all, and studied examples.

I was walking through the Mac factory one day, and the two biggest pieces of automation we put in were a giant small parts storage and retrieval system; there were these totes that ran around. And the second one was this giant burn-in system at the end; a few tens of millions of dollars worth of equipment. And I realized, unfortunately too late, that both of them are warehouses. They’re just high-tech warehouses. So when we looked at NeXT, we said, “No warehouses of any kind. We have a true JIT factory. Stuff comes in and is delivered right to the point of use on the factory floor. There is no warehouse. Deliveries are made daily, sometimes more frequently than that. There is no outgoing warehouse. Everything is visible.”

And the reason that we were able to do a lot of what we’ve done is because when we were learning about manufacturing Mac, we hired a Stanford Business School professor at the time named Steven Wheelwright… And he did a neat thing, he drew on the board a chart. The first time I met him, he said, “You can view all companies from a manufacturing perspective this way. You can say – there’s five stages. Stage one is companies that view manufacturing as a necessary evil. They wish they didn’t have to do it, but damn it, they do. And all the way up through stage five, which is companies that view manufacturing as an opportunity for competitive advantage.” We can get better time to market and get new products out faster. We can get lower costs. We can get higher quality.

[47:58] And in general — you can sort of put the American flag here, and put the Japanese flag in here… [laughter] And that’s changing, however. That’s changing. And it’s changing because people like you are going into manufacturing. Big companies are starting to realize that we were great at this one time, and then we took it for granted. Ad people are starting to pay good salaries now and get good people. So we want to be one of these and we try very hard.

By the way, just going back to software for a minute… I often apply this scale to computer companies and how they look at software. See, I think most computer companies are stage one - they wish software had never been invented. I think there’s only three companies here, and that’s us, Apple and Microsoft in stage five. We start everything with the software and work back. But anyway, going back to manufacturing… We started looking at the factory as a software problem. And the first people we hired in the factory were some software engineers; we convinced them to move from R&D into software, which was not easy. We had to give them bonuses, we had to cajole them, we had to promise them they could come back if they hated it… And they went over there, and we said “This is really just a software problem with interesting I/O devices called robots, that’s all it is.” And so we started building the software first.

And our first robots that we got, we spec’d them out, and we bought them completely turnkey, with the robot arms on them and all the electronics, and the software to control them. And we spec’d it out, but we didn’t write it. And they worked okay. Some of them are still in use, but they weren’t great. And being software folks - we weren’t real happy. They weren’t elegant. We couldn’t do what we wanted with the robots. We couldn’t tie in a quality information system to them, and all this other stuff we wanted.

So the second generation, we spec’d out the hardware and had somebody build the hardware for us, but we wrote all the software on our own computers. We’re object-oriented, so we started writing robot objects, quality objects, all sorts of objects to control this factory. And we found out our computer was great for it. And so our whole factory now runs on this object-oriented factory and quality system. The last generation, our latest generation of robots, which we’ve deployed this year, we actually built the hardware.

I’ve been to Japan a lot of times, maybe 30-40 times, and I loved to tour factories over there… And they always amaze me, because they built everything themselves, they weren’t afraid of anything. They needed a robot—they’d try to buy one, but if they couldn’t, they’d actually engineer it and build it. And you’d think this was really expensive, but we found out it’s pretty cheap. It’s actually cheaper than buying them. And so we’ve actually now designed and spec’d our own robots; we don’t mill the metal or anything we get them all made we put them all together, and we do the software top to bottom, and we have now some extraordinarily advanced robots in the factory. And our computers are built start to finish on the key components, completely untouched by human hands.

Preston Thorpe: So at the very beginning, there was no – there was internet access on the laptops, but it was only in the recreation building, where the education department was. That’s where the Wi-Fi was. So you could browse the internet in the rec building, in the education hallways, and stuff. But when you go back to the pod, you go back to your cell, there’s no internet access. So I would save Python documentation… And especially back then, there was – it’s like Windows Active Directory network, and you don’t have any execution policy/privilege. I don’t know if you guys are familiar with the old AD Windows networks, but yeah, your execution policy is turned off, so you cannot install anything. You can run bundled, kind of, where all the libraries and stuff are bundled in the one application, the portable ones… But yeah, it was pretty painful. I had to get a particular kind of terminal emulator, that would – it was all kinds of… I had to use a PIP proxy, that was from a .edu domain, to be able to get Python libraries, and stuff…

And yeah, so after kind of jumping through these hoops, and at the same time kind of constantly bugging staff to install things, and asking for “Hey, I need Git, and I need…” And also volunteering to help out with – you know, they don’t exactly have a bunch of full-time IT staff, and this was a new thing at the time. So I ended up volunteering, and eventually working for the education department at the prison I was at, and ended up helping out quite a bit, just like running the network. And eventually, I think they just got sick of me asking to install things, or for certain privileges… I eventually ended up getting that job, and being able to at least have some level of root access to my laptop. And that certainly made it a lot easier.

[54:25] And yeah, I was just like writing Python, and C, and I wrote my own kind of C standard library type deal… I knew enough to know that I wanted to start from the bottom, and not just learn React, or whatever. I think the usual kind of starting point today would be considered that pathway. I knew enough to know that that’s not what I wanted to do. That I wanted to start from fundamentals.

After some time, I’m in school, and I am working for the education department, maintaining the network, helping fix things, and get laptops ready, and re-imaging and kind of doing the daily maintenance… They started a – I can’t say they started, but people that were enrolled in college, that had graduated and got their bachelors, those – there was a couple that were either in the process of getting their masters, or they were going for their PhDs. And they had gotten this special permission to work, usually with the university that they were attending.

One person was a fellow, and he would teach, essentially – I don’t know, substitute teacher. He was teaching, or whatever, over Zoom, for the school. And people were talking about “Oh, they might start allowing remote work.” They were playing around with that idea, of “Hey, if people can get jobs remotely, we might just sanction it.”

So I actually was the only one that was not a master’s student. And I put in a request to seek remote work, after – I’d probably been learning to program at that point for probably six months or so, seven; maybe seven, eight months. Really kind of completely out of touch with what I actually needed to know, and what was going to be expected of someone, but I just… I just knew I wanted to look for work. Like, I’m spending 12 hours a day, and I thought “Why not?”

And they actually granted my application to – I put in a special request to seek remote work, and it got granted. And in another brilliant stroke of luck, I ended up kind of cold messaging my CEO (now), on LinkedIn. I had heard about the company from someone else that was on my pod, that does work in prison reform… Like, he’s big into that kind of community – criminal justice reform, prison reform stuff… And yeah, I just kind of got a random tip, and ended up getting on a call, Zoom call with my CEO, co-director now, and they honestly had no – probably shouldn’t have hired me considering the situation, but… Yeah, they gave me a shot. And that was pretty huge. That was a great opportunity.

[58:45] And while I was – I was doing open source stuff at the time, and I was writing a lot of Go, and C, and Python… And I was learning Rust at that point. Right around that time is when I got involved in – that was right after Exa was deprecated. So that would have been, I would say, my primary introduction to the open source community. I had certainly made contributions to a few projects before that, but that was the first thing I would consider to be – like, being active in a project. And I don’t know if you guys are familiar with the ls replacement command line…

Neha Batra: I’ve had an interesting journey… So I started off in December 2017, on the desktop team. And so we were working on GitHub Desktop, and it’s basically a GUI for you to be able to commit your changes… And so if you don’t want to use the terminal, or if you’re very new to Git, this is a great tool for you to be able to get your work done without having to worry about the terminology, and committing, and adding, and doing all that stuff in the right order. This is a very natural way to guide you to be productive without having to worry about all the semantics.

So that was my first adventure, was learning about how Git fits into the GitHub picture, figuring out what it really means to talk about developer productivity… And that was an open source project. And then I was working with an async team. At one point I had like someone in Sweden, someone in Texas, someone in Australia… So we were truly async. There’s no stand-ups, there’s no retros that you can do like that… And before I came from Pivotal, and we were like all about agile XP… And so it was like a complete 180.

So with Desktop, I got to do that, and then I got the opportunity to start CLI. And it was almost like the absolute opposite product. I did a GUI for Git, and then I was doing a terminal, like a CLI for GitHub. And so what does that really mean, and what does it mean to use – no matter what tool you do, how do you keep people being productive? And how do you make it so that they can stay focused and focus on the flow? So we got to build CLI.

[02:04:11.17] And then I got the opportunity to become the director of what we called Communities. And so that was a bunch of our products that we were putting together to optimize for open source communities and how we can bring people together and give them an opportunity to be more successful. Either if it’s like financially with sponsors, or bringing the conversations next to the code with discussions, or incentivizing the right behaviors, and letting people have a sense of pride with their profile and achievements. So there were a lot of things that we did in order to figure out what the different ingredients are, and what it really means for people to create personality, and thrive, both on the maintainer side and on the contributor side.

And then I got the opportunity a year ago to take another step into core productivity, which is my current area. And so if you think about the daily developer workflow, this is projects, and issues, and pull requests, and repos… Most people think about that. So it’s about like getting your code in. But there’s so many pieces that come into that. There’s your client apps, with mobile and CLI and desktop, so my old areas have come back… And then also like notifications, and search… What are the different elements that you need in order to be productive on a daily basis? And then I also get to look at our cross company initiatives around accessibility, and paving our path for our frontend architecture, and also being responsible for our monolith as well.

Thomas Paul Mann: Yeah, so that’s always the trickiest question, what to build… Because there’s almost an infinite amount of stuff you can build. So I’ve been an engineer, and there is something interesting, which I still struggle with… But if you’re an engineer, you have this really tight feedback loop. You build something, you compile, which is the first test, and then you test the feature, and it works, and then you ship it. Which is really good, because the feedback loop is essentially seconds. So it’s a really, really short feedback loop. If you’re like a founder - or not necessarily a startup founder; if you’re working on something bigger, the feedback loop is not seconds. It might be months, or even years, depending on what you’re doing. So it’s really, really hard to know what you build, and if that is the right thing to build, because you never really know. Even if some segments maybe show you that it’s correct, it might be not.

So what we always did, and just the only thing that I’ve seen working for me and us in a way, it’s like we were always going where we got the strongest pull from. So whenever we see people are generally interested in something, they keep asking us about something, that’s what we’re doing. And then you see oftentimes more and more [unintelligible 00:59:51.10] So that basically brought us to AI.

So in 2022, end of 2022, ChatGPT came around, which suddenly changed the whole industry. I think nobody - at least myself - has really seen that coming. I even remember in 2020 we had like machine learning startups in our YC batch, and I thought to myself “Oh, machine learning? Yeah, it’s the same, it’s been around for 10 years, but never really lived up to its promise. Let’s see where they are.” [unintelligible 01:00:21.21] replicate. So they’re doing I think quite well with all the wave of AI right now, with all the models they’re hosting, and so on and so forth.

So I think it took everybody by surprise, in a way… And similarly - yes, we had plans, we wanted to do this and that, and it was like “Oh, there’s [unintelligible 01:00:40.01] And for us, it made really quickly click, because everybody was sort of looking for a textbox to insert a prompt. And if you think about Raycast, it’s a textbox that is available everywhere. So that felt like a really, really good fit. So we put one and one together, quickly shipped a beta, saw a huge interest in the waitlist from one day to another… Which gave us confidence, like “Oh, there is something. Let’s go for that.” This basically turned and also into Raycast Pro, which we launched May last year, so almost a year ago… And when we launched it, it was also the moment when we launched monetization. And launching monetization is this really weird, scary thing. We had for three years not really monetized. We put out then the Pro plan, asking people for paying for us… And we’re quite surprised by the response. Because from day one, there was like a huge interest in it, and it was like “Oh, okay.” That’s what you hoped for, but you never really think this will happen, right? Which is another thing - like, basically, we got confidence that this is like the right direction to go for us. And again, we saw where the pull is coming from, and went in… And so over time, we basically said “Okay, there is high demand for that.”

[01:01:59.27] And then we were just working with the community closer together, what they actually want to have from Raycast and AI together. I think there are two things. One, they want to have similar what we did with extensions, where you have access to so many tools across all the other things you have, and combining them in one interface. They sort of want to have the same experience with AI. Because we have so many different AI models, they have all benefits, but they really want to use them the same way with one app. So that’s what we just did - we released Anthropic, Perplexity, Open AI models. They’re all in the same UI, you can use them all the same way, and you could take the model you want to have.

And so I think over time, what we see happening is AI got like a huge productivity boost to many people. People use Copilot, and all other things… And it became really quickly, at least for myself, a tool that I use regularly, and it gives me a lot of value in my daily tasks. So we really see AI is really most powerful on the operating system level, where we operate on. So we want to make the general AI accessible across tools, that it knows about you, that you can connect to your tools, that it really sits there and becomes sort of this assistant that everybody dreams of. Like, the thing that you can just invoke, and you can ask questions, you get the answers, it can perform actions for you… Really like this interface there that is always ready for you, and is always available across devices, tools, and anywhere else.

And I think we have quite a nice position. If you think about it, we have one in a thousand extensions in the store right now, they’re connecting to all the different tools, which I think is a key to really make this a reality. We have the perfect interface. It’s ephemeral, it sits on top of all the other applications… And I think nobody really is interested having an AI chat in all the different software out there. You just want to have one that knows it, but not have it fragmented as we have nowadays with apps. Because whenever you switch those apps, those things perform differently. You need to pay five times for the same thing… So we really see ourselves like “Hey, let’s consolidate that and become basically this interface for it.”

I think the key thing here is not everything needs to be AI. There are many good things that don’t require AI which we want to keep, right? So it’s not that we now do a hardcore pivot and become like a fully AI-driven thing… Like, things like what you mentioned earlier with the launcher, and all of those things - they’re valid things. We need them. And I see them as like the building blocks. And then you can build abstractions on top of that. Some of them might be AI-driven, some of them might be not, but they all fit under the same nice umbrella of a launcher interface, of a command palette, a command bar. And that’s where we see I think those two things really nicely come together… Where, again, we see people pulling us forward, and we work with them to make it happen.

Scott Chacon: I’m not bored of Git… So what happened – I mean, to answer your first question first, I suppose… I left GitHub and I started another company, which was in language learning. And so I kind of got deep into the world of language learning for about five or six years. And then that company - I kind of spun it off… You guys are in the sort of startup world a lot, right? I think there’s two good outcomes for a startup. One is it absolutely does not work, or it absolutely works great. And the worst place to be is in the middle, where it’s like “It’s not not working, but it’s not really working.” And so you’re like “I’m almost there.” So I did that for several years…

Language learning is - it’s either sort of Duolingo, where it’s very cheap and scalable, but it doesn’t work very well practically. Or it’s like [unintelligible 00:22:29.10] or something, or what we were trying to do, which is you’re talking to human beings, and it’s very difficult to scale, and it’s very expensive for users, but it does work very well. It’s more of an in-person language school type thing.

So I kind of got into this world of trying to figure out “Can we bridge this, to some degree?” Because I got very frustrated – I lived in Paris last year that I worked at GitHub, and I was trying to learn French… And so I think like any startuppy type tech person, I was like “I can solve this problem. This is a very difficult problem. It’s one that I feel there must be millions of people that feel this, that need to learn a language for some reason”, and I tried to tackle that. And it kind of worked, and it kind of didn’t work from a sort of business perspective.

And so when that kind of ended, and I spun it up, I was just kind of looking for what else to do… And I also do some angel investing. Since the GitHub exit, I’ve been angel-investing in some companies, and things like that. And my partner and I kind of looked at all of the companies we had invested in, and kind of asked ourselves this kind of fun party question… We did it every once in a while, which is “If you could run any of these companies, which of these companies would you find it most interesting to be a part of, or to lead?” And mine came up with a version control system that we had invested in. And it hadn’t quite worked, but I found it so interesting… It kind of got me back into it. It was kind of nice to take a break for a little while, not thinking about this all the time. I was still using GitHub every day, I was still developing, but I didn’t really look at the problem set. And what they tried to do was more of like a Google Docs – they really looked at version control of saying “How come Google Docs essentially does version control, but does it very, very differently than how software projects do it?” You never commit in Google Docs. You’re not sort of pushing changes somewhere. It’s sort of constantly recording, it’s constantly saving stuff… It’s trying to make sense of it in the background for you.

[00:24:20.00] And it’s there when you need it, but otherwise, you’re not really thinking about it. And I was like “Why don’t we do that in software? Why don’t we just run a daemon and we don’t have to worry about it anymore? And whenever we need information or something, it’s just always kind of been running there.”

I found that so interesting, of just looking at “How come nobody’s really introspected this for a while, or nobody’s really tried –” Every Git client out there is a button on top of a command line invocation that you would run. There’s nothing new. Nobody’s doing anything you can’t do in the CLI. And so yeah, I started thinking about this more philosophically, of like “What are we really trying to do here?” and then kind of going back to first principles and saying “Let’s start over. Let’s pretend GitHub had not sort of piggybacked on Git, but had created its own CLI, or created its own client.” What might that have looked like if we had thought about it from first principles and really tried to say “What would a nice experience for what you’re doing be?”

And that was kind of what started GitButler, is my partner Kiril, who had started Sturdy, and done this other version control system - they hadn’t worked largely because they were trying to move people from Git onto like a brand new version control system. And that’s very, very hard to do. GitHub ran into this all the time - we would go in and try to move people from Subversion and from Perforce or whatever, and it always had to be greenfield projects. It’s so hard to move a whole team, or a whole company, or something. So we got there, but it took a really long time, and it was a fight all the time. But to come from scratch and try to take on Git and GitHub - it’d be like “You should move from that to us, because we’re better.” That’s insanely difficult to do.

So we decided to kind of go the middle route of being like “GitHub’s great. Let’s keep GitHub, let’s just rethink the client side. How do we create stuff to push to GitHub? How do we manage that information and manage that workflow, and help that be better?” And I think that’s a very interesting question, and it’s one that we’re still kind of debating. We’ve been working on this for a year, and we’ve done really interesting things, I think, around virtual branches and stuff that has never really been in the Git world before.

Now I’m looking at Jujutsu and saying “What can we steal from this? There’s interesting ideas here, that can make your workflow easier. Can we pull in some of those ideas?” Can we look at all of the version control systems, whether it’s Google Docs, or Mercurial, or Pijul, or whatever, and kind of say “What works in these systems? What is interesting? What would make my job easier on a daily basis?” and steal that and try to incorporate that and make it approachable and easy to use.

So yeah, that’s kind of the that arc, right? So now I am back in the Git world, giving talks… And it’s interesting kind of what’s happened to Git in the last eight years. There’s lots of stuff. Microsoft’s been investing heavily in Git. Windows - I think they’re using Git as the version control system for Windows. This massive monorepo, with hundreds of millions of files, and tens of gigabytes of data… Stuff that Git could never do the last time I really looked at it, or the last time I wrote the second edition of the book. And so it’s been really interesting to look at it and be like “What all changes have been made in the last decade?”

It’s funny, because like you said, you learn your seven commands, and then you never really move off of that. And then all of this – there’s 10 years of work; they’re still doing an average of 10 commits a day in the Git project. There’s tons of work going into this, so it’s interesting to look at what has happened. So yeah, I’ve been spending a lot of time on that lately. Sorry, I feel like a steamroller… [laughs]

Chang She: The use cases for LanceDB in the community that I see falls into three or four large buckets. One is of course generative AI, RAG, and things like that. And I think there – I think it’s not so much the use of LanceDB that I think is really cool, but it’s the applications that people build with it that is really cool and amazing. And I think a lot of the applications that people build that is cool, that really takes advantage of LanceDB, is things where you need RAG to be very agile, and that you need it to be really tightly bundled with your application. You can call this RAG from anywhere, and have it return pretty quickly, and without too much complexity.

[30:03] And so this was where I see a lot of folks, from your standard chatbots and chat with documentation, to things like productivity tools, where they build things that help people organize their daily schedules, to much more high stakes things in production, like code generation, or healthcare legal, and things like that.

And so there I think typically you see vector dataset sizes, from like the tens of thousands up to single-digit millions of vectors, typically. So production means you really scale up both the number of datasets that you have, and then the number of vectors that you have…

And one of the cool things that I’ve seen, that takes advantage of LanceDB and Lance format uniquely, is there’s a code analysis tool that analyzes your GitHub repository and plugs it into a RAG customer success sort of tool. And what they want to be able to do is say query the state of the database, like “This today, versus yesterday, versus a week ago”, to say “Hey, was this issue fixed or not?” and “What’s still outstanding?” LanceDB uniquely gives you this ability to version your table, and also do time travel. So you can say – any vector database can do “Give me the 10 most similar things to this input.” Uniquely, what LanceDB gives you the ability to do is say “Give me the 10 most similar as of yesterday, or as of a week ago.” And we do that automatically for you.

And then I think the other big buckets are eCommerce, and a search and like recommender engines. This is like the traditional use case for vector databases… And there you tend to see much bigger single datasets, that are, say, “I want to store item embeddings.” Maybe that’s up to a couple of million, up to 10 million. I want to store item embeddings - that could get up to like hundreds of millions. And you don’t have as many tables, but you have potentially very large tables.

And then of course, the last bucket is this computer vision, AI-native computer vision; either generative computer vision, or things like autonomous vehicles, and things like that. And there’s a whole combination of more complicated use cases that enables active learning, deduplication, and things like that… And the thing that is very unique about the use case of LanceDB in there is companies that are managing all of their training data in LanceDB and Lance format format as well. So you can use the vector database to find the most interesting samples, and then you can actually use the tooling on top of the format to essentially keep your GPU utilization high, and keep your GPU fed very quickly during training, or if you’re fine-tuning, or if you’re running evals, and things like that.

Rachel Potvin: Yeah. I mean, this is where – so when I talk about the things you can do to effectively scale, I think I put them into pretty much three buckets. So there’s a lot going on in code health, there’s a lot of advice I have for teams around code health and developer experience, and so on; there’s a lot of advice I have for teams around how to think about decision-making, and then the final one is culture. And culture encompasses all those things, and more. But it’s fine, sometimes something isn’t a team’s problem, right? Sometimes you want your team focused on the product area they’re working on. They should have a mechanism to surface - maybe something’s come up, maybe we’ve noticed something… Where do you bring those problems? Is there an obvious place? Is there a spot where you document, like “Hey, this thing isn’t working. I don’t think it’s for me to fix, but someone should know”, right?

The thing I set up at GitHub, which - you know, it was a learning process; all this stuff is a learning process. I think you’re never done. You never say like “Okay, I set everything up that I need to do, and now my organization is humming perfectly, and I can just drink a Margarita”, and whatever, right? But the Principal Council, which was renamed to the Architects Group, had a backlog where any engineer in the company could add an issue, saying “Hey, I think someone should think about this.” And not everything would get touched, but the Principal Council was effectively the most senior engineers, individual contributors in the company, coupled with me and my two peers, who were the engineering leaders.

[58:13] And so the most senior ICs had hands in the code on a daily basis, were deeply familiar with how things worked, and represented different product domains and infrastructure within the company. And me and my peers held the responsibility for cross-eng prioritization, and funding, and were able to move people around from different teams… I think one thing you want to be careful about is that people don’t develop too tight of an identity to the thing they’re working on, and that you don’t get such siloed teams that it’s difficult to move people and say, “Hey, look, we really need help over here. Can your expertise and what you did in the past come into play over here?”

So me and my engineering counterparts, we’re able to have conversations with people and say, “Hey, can you come work on this problem? We’re setting up a special virtual team to really address this thing. Let’s get this done.” I would always ask one of the most senior ICs to be champion for any decision that needed to happen, and they were responsible for communicating decisions around that specific area, and really - not necessarily being the lead implementer, but mentoring and coaching the people who were taking charge of the problem area. And so yes, it’s fair for people to say “This is my problem”, but there should be a mechanism for important things to get surfaced. Does that answer your question?

Connor Sears: And they looked at it, and they just, “Hey, are you serious? Did you forget to fill this part out?” We were like, “No, we’re doing everything”, and the whole deal fell apart. [laughs] And that was the reason why. It wasn’t that they didn’t believe us. I think even from that standpoint, it was evident that we weren’t scaling ourselves, and that there are natural consequences of that, like whether or not things slip through the cracks. Or in my case, I can’t do all the design, it turns out. It turns out that I need a lot of help with that.

[01:12:09.23] Or that Scott being the only person who can fix the website if a bug pops up, and having to wake up in the middle of the night all the time, and not being able to distribute that burden. I think those are all just very small examples. But I think this is something that we constantly deal with as a team.

Now, there’s this fine balance between being lean - and we do, we try to run a lean, efficient startup that is focused on building a business. We’re not trying to spend a bunch of money just because you have it. I thnk that story is played out, and it’s not one that I want to sort of participate in. So when we spend money, we do it very intentionally, and sometimes what that means is that we hold off hiring a role until it is absolutely painful to not have a person doing this.

But to your point, I think the other thing that needs to balance that out is getting too comfortable just hiring and then saying, “Well, that problem’s solved. Somebody does that now. I don’t have to worry about it.”

For me, personally - as a founder, you sometimes err towards focusing on what you like doing, even if that’s not what’s best for the company. So there’s been times when my focus really needs to be on go-to-market, it needed to be on sales. All this stuff that, before starting a company, I really don’t have that much experience with. I have zero experience, let’s just be clear. But that’s the beauty of startups, is that you’re learning constantly. And it’s not just enough to learn, but like you said, you have to do the job, you have to do founder-led sales, you have to learn everything you can about things that you’re not comfortable with. If anything, a startup puts you in very uncomfortable situations, where you have to sink or swim, you have to learn how to do something. And it could be sales, it could be marketing, it could be a little bit of engineering, it could be anything. Support, customer success - all these things, you can’t outsource it.

Every time I talk to a founder and they’re like, “Oh, I hired a contracting firm that will just handle this for me”, or “I just hired this person now. I don’t have to think about that.” On one hand, more power to you; that’s great. If you’ve found somebody who can do this at a high level, that is great at the job, and that you can put a lot of trust into - fantastic. It’s what everyone is looking for. But I would still say, especially early on, you just can’t outsource core parts of your business.

Finding that balance, it’s a daily – I wouldn’t call it a struggle, but it’s a daily challenge. It’s like understanding, you’ve got to scale yourself, you can only do so much, and you have to focus as a founder on where you can provide the most value for your company. At the same time, you’ve got to understand the different components of your company, and you’ve got to know enough to jump into any conversation and at least have some sort of understanding of what’s going on, while building a team around you that can educate you.

I like being able to get into a room and saying, “Hey, everybody. You know I’m an idiot when it comes to X. So treat me like an ignorant fool, but here’s some questions I have.” And then that age-old question that’s like, “What are the unknown-unknowns for me that you all know I should be asking about, but I’m not asking about?” That helps level you up, and definitely, it’s one of the things I’m most proud of is the team that we are building, that can bring that expertise to the table, and feel comfortable to talk to me when I’m not thinking through something deeply enough. Because oftentimes, I look at something and it’s a bunch of arrogant people do like myself, I say “This is simple. It isn’t that complicated”, and actually it is. “Okay, cool. Let’s talk through it and let’s figure this out together.”

Matt Brems: [23:48] Yeah, of course. We were talking before the break about people who want to get into the field, and the options they have. Some people may go to a college or a university, some people may go to a General Assembly, some people may be trained by their company in some way, or they may self-study… There’s a lot of different options out there, and I think that it all comes down to a couple of dimensions, for most people. I think that people think about the time investment, people think about the monetary investment, I think people also think about - related to that monetary investment - the opportunity cost… For example, if they were to leave work and go to General Assembly, or if they left work to go to grad school, or if they went to grad school at night. And then also, the practicality of the skills that they’re doing, the hands-on nature of the program.

Where I personally think that General Assembly sets itself apart is it provides, like I said, this three-month program to take people from approximately square one to be well-qualified for entry-level data science roles, and people are often able to get more senior roles, depending on their backgrounds coming in.

I think that a great deal of that has to do with the applied nature of our program. I think when you ask where GA fits into everything, I think General Assembly fits into it just because of it’s applied nature. Like I shared earlier, I did a master’s degree in statistics, and I learned a ton of really good and important things in my master’s program. At the same time, there were a lot of things that were not as applied as I would have liked them to be. As an example, I can’t recall working with any data that was missing in my grad program. I’m sure that you both recognize how much missing data we deal with on literally a daily basis in the practice of data science, and how we choose to deal with that is a problem and is a challenge for us.

I think that with minimal exception, the largest dataset that we worked with in grad school was probably about 200 rows, whereas that’s not the case in most data science roles. Everything was already sanitized, and we just focused on building a model instead of thinking about everything else that goes into it.

So all of that is to say I think where GA fits into that is for people who say “Look, I want to commit to learning skills”, perhaps they need more of that personal – “oversight” isn’t the right word, but maybe somebody who says “Look, I don’t have the responsibility to do that myself. I don’t know if I could sit down and learn data science on my own, start to finish, so I need some support in getting there. And for people who are looking for specifically practically-applied skills, I think that’s where General Assembly fits in the broader landscape of things.

Beyang Liu: Yeah, I’m happy to spitball. I just wanna declare upfront that as of now we’re not working on any sort of machine learning related thing. As a person of a machine learning background, it kind of rubs me the wrong way. A lot of companies say they have some fancy machine learning algorithm and really, it’s just Mechanical Turk underneath the hood. I just wanna make it clear that Sourcegraph is not doing that.

If and when we do use machine learning, we wanna have a very clear use case in mind. Now, that having been said, one of the things that got me really interested in this problem in the first place was as a person who likes data and thinking about how to model it, the dataset of all the code - it’s got two properties. One, it’s extremely interesting because it’s such a valuable dataset and there’s so much information that’s embedded in it. And two, it’s relatively unexplored. There’s not a lot of tools that are specifically designed for reading and understanding that data. Most of the tools are optimized for creating the data, actually writing code. And so from the get-go, this has been something that’s been in the back of our minds.

Just to name a few things that we could do after we’ve collected the dataset, kind of half-baked ideas… One is kind of intelligent auto-complete. We think of auto-complete as this thing that just cues off of compiler signals and it gives you a list of all the possible tokens that are syntactically, semantically correct, to use at a given point of file.

[59:49] But what if you could actually go beyond that and suggest a variable name or suggest a parameter value based on the surrounding context? Now, that prediction problem is a lot fuzzier. You probably wouldn’t be able to get that just from heuristics and what the compiler tells you alone.

That’s probably something that you wanna learn, like “Okay, I’ve seen this pattern before in code.”, this pattern AST and in the past, when I’ve seen the token read, for example, and now this user is calling some function that writes a file, and what if they’re passing you the wrong value of the permissions flag? They’re setting it to 0666 instead of 0777.

Given enough data, you could probably learn some interesting patterns there for what things to flag to the user that “Hey, maybe you’re hitting this API incorrectly because you’re using it in a different way than the hundred other people out there in open source use it.” So that’s kind of like one half-baked idea we have in the back of our minds.

Another problem which is kind of related to that is in order to do that prediction problem well, a sub-problem you kind of have to solve is the scoring problem. Machine learning, the way you’d phrase it is given this piece of code, give me the probability that this piece of code exists or is valid. So you give it a likelihood score, and what that tells you is, if you see a piece of unlikely code, like a piece of code that your model thinks is like, “Oh, that’s kind of interesting,” more likely than not it’s an error and you can flag that sort of thing.

So you think about running this model, you train this model on all the code in the world, and you discover associations of specific words and doc strings and parameter values and function calls. Once you’ve trained it, you run it on all the code in the world and you can kind of give a print out to people saying like, “Hey, in addition to the linter errors that you already get, here are some places where you might wanna think about how you’re calling this API” or “Hey, senior engineer, one of your jobs is to make sure that the other people on the team aren’t shooting themselves on the foot or incurring a lot of tech debt. Here’s a daily print out of hotspots that you might wanna scan that are model-discovered.”

Both those ideas are very half baked, I haven’t really explored them seriously yet, but I think, you know, given the structure of this data set and how novel it is, there’s bound to be some great low-hanging fruit in there.

Sam Lambert: I think my appreciation for anyone that’s managed to build a successful company, and learning from them. I think we oversimplify what it takes, and the immense emotional burden that it puts on everyone involved in doing so… And I’ve gained an incredibly strong appreciation for that, and I think it’s made me a lot less critical about this… Because you kind of walk a mile in their shoes and you’re like “Yes, it’s hard.”

I’ve tried to be more disciplined, I’ve tried to stick to more of a routine, I’ve tried to be less reactive to just general things that happen, and just more focused. Because I’ve realized that scope creep and time creep – you have to be so much more discipline with your time, because no one will value your time as much as you will yourself. And a loss of time, and burning and wasting time has and can have an extremely detrimental effect on you and your company. And at the end of the day, I just wanna bring home a massive win for everyone that’s come to this company and is here building something, and I wanna deliver something amazing for our users. I take that just extremely seriously, and it just takes daily thinking and iterating over the problems continually.

And look, I don’t want anyone to listen to me and think that I’ve made it, or there’s any advice here worth taking… You have to find your own path. But I think just dedicate to be learning and seeing how you’re wrong… And you kind of learn that over and over again, and you really see the effects of your decision compound over time, and it’s very stark. It’s great to have that kind of challenge. I think it makes you better if you’re dedicated to being better.

Chris Ferdinandi: Yeah, there’s just a couple things… I am a self-taught web developer. I started doing this actually right around the same time as Divya. Her and I met right at the start of our respective careers at Artifact Conference in Providence, Rhode Island (super-awesome). We’re both speaking there, by the way, this year, so if you guys can make it out there, I highly recommend it. It’s gonna be awesome.

I started off my life as a developer knowing purely HTML and CSS, and partially out of a lack of ability to find meaningful employment, and also partially because as a self-taught developer I didn’t feel like a real developer, because I didn’t know JavaScript. I started teaching myself JS, and somewhere along the way I transitioned from learning this stuff in jQuery to wanting to really understand how it all worked under the hood. And then when frameworks started becoming more and more of a thing, I started feeling more and more like they were just making all this stuff way too complicated, and just never really dug that whole thing. No disrespect, Divya, because I know you’re all-in on Vue…

Over the last five or six years I’ve really become a specialist on all things native, plain, out-of-the-box JavaScript. And one of the things I really struggled with early on was the fact that because it’s not owned by any one group organization, there was no single source of documentation. The types of tutorials you’d find were varied in quality, and a lot of times you’d have to cobble together your own comprehensive education from a bunch of different resources. Stack Overflow can be awesome, but if you’re a beginner, they can be sometimes a little bit hostile to beginners, and questions are deemed too like obvious or entry-level.

[04:04] So I started creating educational resources to help other people who were going through the same thing. It started off just me blogging about the stuff I was learning, and eventually evolved into a daily newsletter, than a set of eBooks, and videos courses, and eventually a full-on eight-week training program. Now I have this video subscription series thing I do, where people can code along with me in real-time and work on vanilla JS projects.

It’s a lot of fun. I didn’t expect this to turn out the way it did, but it’s been kind of an interesting journey for me.

Mislav Marohnić: Well, Go was a very short discussion with the rest of my team, all of whom other than me were unfamiliar with Go; they were familiar with it, but they were not using it for anything of substance up to that point in their engineering careers.

[31:56] And I had pitched the Go idea mostly as a way to preserve what already we know worked well, and that was - well, I’m a big fan of its compiler; I think it’s very robust and it gives me a lot of confidence in it while I write code, together with a good integration with Gopls for instance right now in the text editor, and having this confidence that everything is wired up properly through static typing… And for me, that was a big departure coming from very dynamic languages like Ruby, and into learning how to let go of that mentality and become very secure in the static typing mentality.

Another of the qualities that we wanted to preserve is portability. I remember it being a very short conversation, because my colleagues were just evaluating those things and thinking about potentially other languages we can write it in… But all of that I just mentioned resonated with them, so they were absolutely on board with “Alright, we’re learning Go now”, and through the next few weeks and months they went from basically zero to also doing Go like me right now, on a daily basis. I would say that they surpassed already my abilities, because I sometimes feel I’m catching up to the rest of my team.

Bill Dally: That’s a really good question. The short answer with the future of AI is continued rapid innovation. I expect to continue to have to stay up late every night, reading papers on archive, and even then not be able to keep up with what’s going on. But if you look at how that rapid innovation is happening, I think it’s along several different axes.

The first axis I think is breadth of applications. I think we’ve only began to scratch the surface of how AI is affecting our daily lives, how we do business, how we entertain ourselves, how we practice our professions… I expect more applications of AI to be occurring every day, and those applications to present unique demands - the type of models we need, how we curate training data, how we train the networks with that data and so on.

The next axis I would say is one of scale. Scale of both model size and datasets. We’ve seen this in areas like computer vision, in speech recognition, in machine translation, where over time people collect larger data sets, to have the capacity to learn those datasets they build larger models. That really raises the bar for the performance you need to train those models on those large datasets in a reasonable amount of time.

And then finally, the axis that’s probably most exciting to me is coming up with new models and new methods that basically increase the capability of deep learning, to be more than just perception, to basically give it more cognitive ability, to have it be able to reason about things, to have longer-term memories, to operate and interact with environments… A lot of the work in reinforcement learning we find very exciting along that axis.

[27:52] Seeing this constant innovation on all three of these axes - our goal with our platform is to evolve to meet these needs; to meet the needs of newer applications, to meet the needs of larger scale and more capable models and methods… And there’s a couple ways we need to do that. One is to continue to raise the bar on performance. To train larger models and larger datasets requires more performance, and Moore’s Law is dead; we’re not getting any more performance out of process technology, so it requires us to innovate with our architecture, with our circuit designs to do that… And we’ve done that generation to generation. If you look at the performance from Kepler, where we started working on deep learning, to Maxwell, and Pascal, Volta and now Turing - we’ve been able to really increase by large multiples deep learning performance on each subsequent generation, in the absence of really any help from process technology. We expect to continue doing that.

The next thing we need to do is we need to make it easier to program, so that people who are not experts in AI, but are rather experts in their domain, can easily cultivate a dataset, acquire the right models and train them. We do that through our tools; we support every framework. We have TensorRT to make it easy to map your applications onto inference platforms…

And then we also have training programs. We have a Deep Learning Institute, where we basically take people who are application experts and train them so that they can apply deep learning to their application.

Then the final way we want our platforms to evolve is to remain flexible. The deep learning world is changing every day, and so we don’t wanna hardwire too much in and not be able to support the latest idea. In fact, we think it would inhibit people coming up with the latest idea if the platform that everybody is using was too rigid. We wanna make it a very flexible platform, so that people can continue to experiment and develop new methods.

Nhung Ho: Well, I can tell you it’s dang hard… [laughter] That’s the short answer. One of the things that we got creative with in the forecasting example is – well, let’s take sales as one type of input forecast. Traditionally, you take your sales in the past, and then you can project that forward; standard time series forecasting. What we were seeing during the pandemic is that there are actually a lot of customers who have extremely sparse data, because what used to be daily sales are now turning into maybe once a week you’re getting a sale [unintelligible 00:34:14.06] and that was the totality of your sale. So incorporating that in, and being able to deal with sparsity of data is one way that we folded that in.

There’s also actually learnings to be had. This is where you can actually transfer the models that you build from one business to another. There are certain businesses who essentially all of their sales and all of their events happen once during the year. My favorite example is a Halloween store. It is a very short lifetime for a Halloween store, where they have nothing, they have everything, and then they have nothing again, for a while. So for those, we actually can take the models that we’ve built for them, learn from them and actually apply them for companies who are going through somewhat similar events right now. So that’s why it’s been advantageous to have that broad view across the industry, and being able to transfer across.

Suju Rajan: But it is true - maybe ten years ago it was behind the scenes and nobody really talked about it. “Hey, why do you see the results that you do? Why are you being shown the ads that you have?” It was not really a part of the discourse, but I think all of these interesting innovations in terms of – I wanna call it the PR events that some of the big companies sort of set up… They helped the field get the recognition that it perhaps deserves to have, given how integrated some of these models are into our daily lives. You know, the fact that whether I get a home loan or not perhaps has a machine learning model behind it; it’s important for folks to be aware of it.

I would say it’s a combination of both. It feels like a new space because there is a lot more recognition of the fact that it is very integrated. Data-driven decisions and AI models are never going to go away from now on, so how do you wanna think about this field from a societal standpoint I think deserves conversation, and that’s how we make sure we don’t make the wrong choices.

At the same time, open sourcing has become a big deal, with TensorFlow and PyTorch and all of these larger companies “democratizing” it, as they call it… Like, “Hey, get onto AWS and you have SageMaker and the whole lot of it. Just give us your data.” And the fact that it is becoming a lot more accessible means that a lot more folks are also interested, without having to – you know, in the past it used to be you had to go to this lab, you had to get a Ph.D, you had to publish papers before you can even think about machine learning. The barrier for entry is a lot lower these days.

But given the ubiquity of the application, I think it’s important for everyone to understand what AI can do, and the implications that it has. So - for the better, but I wish we didn’t have as much media attention. [laughter]

Chris Benson: [32:14] Yeah, really. There was a – I won’t name the book; I’m not sure if I can remember it, but a friend of mine asked me to read a book, and I stopped at the first chapter, because the whole premise of the book was like DARPA, which was like this spy agency, was sending agents out into the field to do nefarious things, and I was like “I just can’t take that.” It’s so far from reality.

What DARPA is essentially - and this will probably offend them, do dumb it down this much… But it’s essentially a giant project management office. Their mission is to look at what are the next great technologies that are gonna lead us into the future… And many of those things, even though they may be looking with a military view, end up out in the general population, just as the internet did. So it really does affect our daily life, eventually.

They have a 3,5 billion dollar budget, which is a nice, hefty little sum of cash to go try to figure out the future with. And another really cool thing that they do is that it’s impossible to be a career DARPA manager; they do rotations. And I forget what the exact time limit is… I think it’s four years (it might be three), but you never can bet your career on your DARPA performance. And the reason they do that is they want people to take risks. They want people to be willing to make big bets without it being something that will destroy their careers. So it’s the safe place to do really revolutionary work… And that happens. Essentially, the entire organization is a bunch of project management offices, and stuff.

The reason I say all that is that they have - it’s actually not terribly recent; it was back in 2018 - released a PDF that’s open to the public, anybody can look it up, called The Three Waves of AI. You can google it and find it instantly. And it basically segregates the history as they see it of what AI is and is going toward… And the three waves - and if you think of the past one, it’s what they call Handcrafted Knowledge (I’ll talk about that in a moment), the current one that we’re in is Statistical Learning, and then the future that they’re talking about, the third wave of AI, is called Contextual Adaptation.

I think the short, quick version of each of those is that if you have a set of attributes about how sophisticated you’re getting with your AI in terms of perceiving, learning, abstracting and reasoning, and how far each technology can go that we’re at… And if you think – like, an example of first wave, which was previous, before we got to the current deep learning period, would be like an expert system. That’s where you capture a whole bunch of rules into a system, and you have a flow that goes through them… But it’s a rule-based system. So it’s not inference, it’s not prediction in the way that we think of it today. It’s not statistical, it’s following a set of rules…

And then we eventually got to this point that we’re at now, where we’ve been in this amazing deep learning revolution of recent years, which they refer to as the second wave of AI… And in particular, things like perception and learning have come a long way up that. We haven’t made so much progress in abstracting and reasoning, but the idea is that we are learning, and even in the short time we’ve been doing this over the last few years, we’ve come a very long way in terms of what we can do with those statistical capabilities… But as we started this episode with, we’re starting to get a little bit mature about where we’ve gotten to, and we’re starting to see mini-versions of the same models and technology coming out.

So what DARPA is really looking for are organizations - academic, industry, within the military itself, that are interested in this idea of contextual adaptation, where you’re essentially pushing all of those characteristics as far as you can, and you are able to perceive, form a contextual model, and learn, abstract, reason, and really all of those concepts that really lead eventually to the AGI concept that we’ve been talking about, are seeing at least the next stage of realization. There may be many waves after this potentially, but it’s kind of taking us from where we are now in 2020 as we record this, into the next some-odd years of what this is likely to be.

[36:23] So that framework - I keep coming back to that in my own professional life, and I think it’s really important that we start recognizing that maybe we’re seeing a fairly mature, statistical, learning marketplace, if you will. And people are able to put into production all these great deep learning models… But a lot of the really cool research, as we saw with that NeurIPS keynote, are now focused on what in this context would be the third wave, and what in that context was system two.

Craig Wiley: Yeah, so TensorFlow is - for those who aren’t as aware - the premier deep learning framework for building these neural networks that have become so transformational in the journey of artificial intelligence and machine learning. TensorFlow is an open source project, started and led by Google, but with contributors from all over the world, and for many different companies and corporations and organizations.

[07:54] At the end of the day, when I think about TensorFlow I think about the ability for people to do increasingly complex tasks easily, so that they can get to the point of value creation faster. Now, you asked about how we sit organizationally, and things… TensorFlow is a part of our Research Group, and internally has a charter or mandate to ensure that Googlers have the best tools they need in order to build the kinds of assets, the kinds of machine learning tools and assets that they want.

Having said that, in cloud with work hand-in-hand with this group (to be honest) probably of folks who are not in my direct org. This is probably the org I am closest with, meeting with them on a daily basis to figure out how we can provide more value to TensorFlow users, and how TensorFlow can provide increasing value to Google and Google’s cloud customers when need be.

Chris Benson: I will dive into the last article before we go into learning resources… Periodically, we will talk about the world of medicine being impacted by AI; it’s come up in several episodes prior. The physics world had an article called “Deep learning algorithm identifies dense tissue in mammograms.” The Massachusetts Institute of Technology (MIT) and the Massachusetts General Hospital developed a deep learning algorithm working together that assesses breast density in mammograms, and it does so very reliably. This provides a tremendous tool for mammographers - if I’m saying that right; doctors in this field - to be able to use to help save lives.

Apparently - and I wasn’t aware of this specifically before I read the article, but dense breast tissue apparently masks cancers on mammograms, the common mammograms that people are getting every day these days. It makes the screening more difficult, and apparently that can be an independent risk factor for breast cancer, the presence of it. In this case, the researchers trained and tested the algorithm on a data set that was 58,000 digital screenings that were mammograms. They divided that up into 41,000 for training and 8,600 for testing, and then during the training, the algorithm was given random mammograms to analyze, and in doing so was able to predict the most likely density category, which enables these doctors to save lives.

[24:10] This inspires me. I come from a family full of women; I’m the only boy, I have four sisters, and I have a daughter as well, and my wife, and my mother, and I see the impact of these things in their daily life, so I was truly inspired by what’s happening in this field, and the fact that these doctors are getting better and better tools every day.

Linus Lee: I could take a stab at it… So I’ve been using Go in one form or another for at least 2-3 years, I think, between when I wrote my first Go project… I’ve written Go professionally a little bit; I’ve squeezed into some projects here and there that aren’t what you’d call production products, but that are infrastructure, or testing services, or things like that, just because it’s a nice thing that you can build.

One of the nice things about Go is that we value stability a lot, so if you write a thing and it’s not maintained daily for a few months, it doesn’t break over time… But most of my usage of Go has been on side projects, on things like the thing that we’re gonna talk about today, but also other things, like little chat clients that I’ve written… Learning exercises.

Jerod Santo: Gotcha. So yeah, much more people using other browsers – that’s a good thing, right? We have people testing in browsers that they’re not using on a daily. Much more representative - Safari Edge, Safari iOS, IE, Chrome Android etc. etc.

Which form factors do developers test on? Pretty much everybody tests on desktops. 99.7%. Only a few hundred people are not even using a desktop at all to test, which – what’s wrong with you folks? You’ve gotta test on desktop. 91.6%, so it drops off a little bit for smartphones, but still, a pretty good penetration in terms of testing on phones. Tablets 70%, so on. You can read those results for yourself.

Let’s get to this Opinions section. I thought this was cool. We’ll close with this one here, I guess, and maybe have you state some of your conclusions, Sacha, as we tail off the call.

This is a section which is basically like you answer “Do you agree with this? Do you strongly agree? Do you strongly disagree?” Kind of a sliding scale, and it has a bunch of statements about CSS.

I thought this was a very cool section of the survey. The learning curve for CSS - the statement is “CSS is easy to learn” and… Pretty high agreement. 35% agree, and then another 25% (rounding) strongly agree. Pretty much nobody (and by nobody I mean 340 people) strongly disagree with that statement. So CSS still, even though it’s evolved and added a bunch of stuff, and people get caught up with how to select your precedents and all that stuff - there are things… But overall it seems like people are thinking it’s easy to learn.

Speaking of evolvement, “CSS is evolving too slowly.” This is one that I thought I would see more agreement on, but most people are pretty much neutral on this. Did this surprise you, Sacha? Does this reflect what you think about the evolving pace of CSS?

Adam Stacoviak: Yeah… Wow. It takes learn by doing, in most cases; iteration, patience… There’s so many people who are so hard on themselves, especially programmers… Because you’re often in uncharted territories; on the hourly, on the daily. So having patience for yourself and your own learning process, and understanding that you are gonna struggle - because we’re human - but then figuring out how to get around those, or just giving yourself some slack by saying “You know what, I’m only human.”

Arfon Smith: Yeah, I think the kind of insight into how software that maybe you maintain is being used is one of the most powerful ones that I think of here. Because for example, say you are wanting to make a breaking change to your API - actually one of the project I maintain on behalf of GitHub, a project called Linguist, we wanna change one of the core methods, actually one that detects the language of the file. We wanna change its name and we wanna re-architect some of the library, and we know it’s a breaking change to the API and we have had deprecation warnings out for 12 months, but honestly being able to run a query that sees how many times people are actually using that API method still, helps me as a maintainer understand the downstream impact of my changes. And currently, that’s just not been possible before. And of course, you can’t see what’s going on in private source code, but a lot of this stuff is in open source repos as well. Being able to drill down into source code, all of the open source code that’s on GitHub… And for me the other kind of killer feature is like, to be able to do this you wanna write a regular expression of some kind right, and being able to run regex across four terabytes of data or three terabytes of data - we should actually figure out what the exact number is, it increases daily of course, but being able to run a regex against all that data is incredibly powerful and something that has just not been possible before.

Wanny Morellato: Yeah. You need to understand the space you are in, what you are okay with, and we are not okay with, so that you can make the right decision. And you can decide if you - going back to what I was saying before, if you want to dedicate a sprint to update your dependencies, or if you want to do it during your daily work. It depends on what you’re doing. And I think we need to trust and empower the engineers that are responsible for that service to make that decision. I don’t think there is some top guidance that applies for everybody. Just give them the tool, give them the knowledge, give them the automation, and they will have the context to make the best decision. And that feedback loop to keep making things better and improving and learning always exists. But then the responsibility [unintelligible 00:54:23.09]

Whitney Lee: Oh, goodness… I mean, I’ve been working really hard; I have a daily study routine, and I did my very best, and I’m learning at a breakneck pace… Teaming up with Mauricio certainly doesn’t hurt anything, since he certainly knows his stuff… And then I make a show called Enlightning. Sso I’m in the public eye a little bit… At least enough to know that I’m pretty natural in front of a camera, and that I can articulate ideas well… And I don’t know, maybe they just made a mistake somehow, and I just capitalized on it. That’s always a possibility too, right?

Jerod Santo: Because every time I have to use jq, I have to feel like I’m learning the query language for the first time, because I use it infrequently. I think if I used it daily, it would be less so. So it sounds like this is really great for discovering how that query language works more in a tactile way.

Jerod Santo: Because every time I have to use jq, I have to feel like I’m learning the query language for the first time, because I use it infrequently. I think if I used it daily, it would be less so. So it sounds like this is really great for discovering how that query language works more in a tactile way.