Embedded - 267: Cute and Squishy

Episode Date: November 9, 2018

Lindsey Kuper (@lindsey) spoke with us about !!Con West, being a new professor, and reading technical journals. The call for speakers for !!Con West is open until November 30, 2018. The conference will be in Santa Cruz, CA on February 23-24. Lindsey’s blog is Composition.al and it has advice for !!Con proposals, advice for potential grad students, and updates on Lindsay’s work. The Banana Slug is the UCSC mascot. Time, Clocks, and the Ordering of Events in a Distributed System by Leslie Lamport, 1978

Hello, and welcome to Embedded. I am Elysia White, here with Christopher White and, in person, Professor Lindsay Cooper. We're going to talk about a neat conference she's working on and some of her academic career. Hi, Lindsay. Thanks for being on the show today. Thanks for having me. Could you tell us about yourself as though we came to one of your seminars and had never met before? Sure. Well, as you mentioned, my name is Lindsay Cooper. I'm a new professor of computer science at UC Santa Cruz, or I should say computer science and engineering. That's the new name of our department. And my research area is the intersection of programming languages and distributed systems.

And I'm also a co-founder of BangBangCon, which is what I'm here to talk to you about today, which is a conference of 10-minute talks about the excitement and joy of programming and computing. Cool. Well, we do this thing where we ask you short questions, and we want short answers, and if we're behaving ourselves, we won't ask you how and why. Are you really sure about Rust? So, Chris, do you want to get started? Sure.

Research or teaching? Both. Preferred code editing tool? Emacs. What percentage of students do you see go on to get graduate degrees? Oh, well, that's a tough one. So I'm new to UCSC, so I couldn't really give you a percentage of undergrads, but I hope a lot of them. What percentage of software professionals do you think should have graduate degrees? Oh, well, that's also a really tough question. I really don't want to make any claims about should.

Okay. For some people, it's the right choice, and for other people, it's the wrong choice. What if they get a graduate degree in something nothing to do with software? That sounds fantastic to me. What was your favorite class you took during your academic career? development and i've i've written about why i like this class so much but uh the the short version is that uh we spent a semester 15 weeks writing a compiler and we wrote it back to front which went meant that we we started by writing the last pass of the compiler so the the first assignment in the course was to write a uh a compiler from something that was a very thin layer over x86-64 assembly that produced x86-64 assembly. And then the next week,

we added another layer on top of that. And the next week, another layer on top of that, and so on. And so it was great because every week you had a working compiler from a slightly higher level language to assembly language. And it was incredibly motivating because, you know, a lot of times in something like a compiler course, you write different pieces, but it takes a long time before you actually have something that can be thought of as a working compiler. And in this course, I got to actually write a compiler every week. And, you know, it was a compiler for an increasingly higher level language that at first was only very, very different, very, very similar to the output language. But it was still incredibly motivating to do it this way.

And it also, it encouraged you to structure your compilers, this series of small passes, which is really nice for a lot of reasons. So I got a lot out of that class, even though in later compiler work that I did, I didn't use very many of the specific things that I learned in that class. It was the fact that I took that class at all that made me realize that working on compilers could be really fun. Well, now I think this is really going to be a softball. What is the class you'd most like to teach? Oh, boy. Well, so right now, I'm almost in the best situation imaginable because I got to teach a, as my first course at UCSC, I got to teach a graduate seminar on whatever I wanted. So I have six students in the class, and we are, it's a research seminar on the intersection

of programming languages and distributed systems, which I mentioned is what I work on. So we're looking at programming languages-based approaches to implementing and verifying distributed systems. I have many questions about that. Should we give up on lightning round? No, I think you have to ask the last question. Ah, what can you tell me about banana slugs that I might not know? That you don't know? Well, you're the one who's lived around here longer than I have, so you probably know all the banana slug facts. But I saw a banana slug in person on campus not too long ago. They are indeed cute and squishy.

And sometimes up to 10 inches. How big was the one you saw? It wasn't that big. I would say it was like maybe four inches. Still pretty big for a slug. Yeah, not bad. And a bright yellow slug. Okay, so let's talk about this seminar. Distributed computing and languages. I think about distributed computing. I've done ShotSpotter where we did gunshot location systems spreading sensors around a city and automatically calling police. So I think of that as a distributed system.

Is that what you think of as a distributed system or do you have a different term yeah i would call that a distributed system so yeah so there's no uh universally accepted definition of a distributed system leslie lamport had kind of a funny definition where he said a distributed system is uh when some computer that i don't even know about can fail and render my computer unusable. And that's a joke, but there's actually a lot of truth to it. So, let's think about what he's saying there. So, if some other computer exists and can fail and render your computer unusable, well, so there are at least two computers that we're talking about here, and they're talking with each other in some way, and one of them can fail. So, these are kind of the essential pieces of distributed systems. You have computers, more than one, they're communicating with each other, and failures can happen. And

there are different ways to define what failure means, but those are the essential pieces of the definition. My colleague Peter Peter Alvaro, would add another piece to this definition, which he would say there's unbounded latency in the communication between these computers. And that's kind of like failure as well, because if it takes an unbounded amount of time for a message to get from one to another, then it's as though it has failed. And languages. I mean, I work in embedded systems. I don't get a lot of choice of languages. But what difference do languages make in distributed systems? I understand they're parallel computing, but...

Sure. So working on programming languages really means working on figuring out what are the right abstractions to solve a particular problem. And with all of the challenges that distributed computing comes with, this unbounded latency, failure, communicating between machines, which introduces all the usual issues of concurrency, sometimes it's hard to solve these kinds of problems without having the right tools. And the right language can provide you tools to help think about your problem in the right way. So what I work on is trying to figure out what are the right abstractions for addressing the problems of distributed computing. And I work on parallel computing too, which you mentioned. Can you give an example of something that might be hard in one language that becomes clear in another language? Well, there are all kinds of trade-offs when

you're choosing what language to use, right? One of the traditionally accepted trade-offs is that you have to choose between expressing things at a high level and doing things fast in a high performance way. Yes, yes. Right? So, and this is probably a trade-off that you're familiar with as a programmer. So, one of the things that I've discovered or learned over my years of studying in this area is that the trade-off is not always necessarily between expressing things at a high level and having high performance. It's more of a three-way trade-off. So you can have expressing things at a high level and also have

high performance, but you have to be willing to sacrifice generality. In other words, you could have a domain-specific language that lets you express things with the right abstractions for that domain, and it can also be very efficient, but you have to give up on a certain amount of generality. So sometimes that's the right choice. And there's been a lot of work on domain-specific languages for implementing consensus algorithms, for example, in distributed computing that optimize for both high-level expressivity and efficiency because they sacrifice generality. So just to make sure I understand, when I hear what you're saying,

I'm thinking about GPUs, that they are very, very fast, but they are focused on graphics to the exclusion of other problems. So they're fast and they're expressive. They can do a lot, but they're mostly for graphics. And the fact that we're cheating and using're expressive they can do a lot right right but they're mostly for graphics and the fact that we're cheating and using them for machine learning is completely separate no it's because graphics uses a lot of linear algebra so yeah yeah so that's a good

example um yeah uh my colleague jokes that gpu actually just stands for general parallel unit now yeah uh because they're they're being used for so many things that aren't graphics. But yeah, this trade-off that I'm talking about between expressivity and efficiency and generality happens really at every level of the stack. It's not just languages. It's also hardware and storage systems and whatever else. So this trade-off, you're going to find it appearing in a lot of places. At lower levels, at hardware levels, you also have cost in there. But at the language level, the cost is the time to produce it, which goes into the expressivity and generality. Yeah.

So what languages are you talking about? I mean, C and C++, I work in those a lot, and Python. But I believe I saw Julia on your resume at some point. Yeah, so I did do some work on Julia. I was at Intel Labs for four years before I joined UCSC. And so I worked on a project called Parallel Accelerator, which was about parallelizing Julia code. And so Julia, let me tell you a little bit about it. So Julia is a language that I think of as kind of a better replacement for MATLAB. It's a language for scientific and technical computing. And it's

in the same sort of space as MATLAB, but it makes some, let's say, more principled design choices. It's got a modern package system. It's open source. And it's got some interesting features. So in particular, one of the things that it has is a macro system, which is kind of unusual for a language like that to have. And it also has some interesting sorts of introspection features, which allow you to do things like, for example, you can write a Julia function, and then you can write Julia code that will actually let you,

or you can call a Julia function that will actually let you see. So Julia compiles to LLVM and you can ask Julia what the LLVM IR is for a particular piece of Julia code. And you can do that right in your Julia code. So this sort of introspection ability is pretty unusual for a language like this. And what it adds up to is that Julia itself actually ends up being kind of a good medium for doing language development. And so, large parts of Julia itself are written in Julia. And if you can imagine trying to implement MATLAB in MATLAB, that would be really weird but in julia this is actually a reasonable thing to do and my group ended up leveraging this and so we ended up building some tools on top of julia that

kind of intercept the julia compilation process and at the time julia itself didn't have any when we started working on this julia didn't have any native support for parallelism. So what we did was we intercepted the Julia compiler during a certain stage of compilation and then compiled that to OpenMP C++. And then we were able to compile that to parallel hardware using an off-the-shelf C++ compiler. And then those pieces of code could be mixed in with regular Julia code. So you could parallelize certain pieces of your Julia code using this tool that we developed. Is Julia a language that's scripted or pre-compiled? So Julia is a JIT compiled language.

Okay. Like Java, just-in-time compiled. That's right, yeah. Okay. And I know Java has some other just-in-time compilers you get for speeding things up. So this sort of is making sense. I don't want to lump Julia in with Java. Oh, no. I mean, I did that, not you. Okay. So Julia compiles to LLVM, but it's just-in-time compiled. So it's typical to use Julia in an interpreter sort of setting. So there's a read-eval print loop, a REPL, where you typically interact with Julia. So in terms of having totally pre-compiled binaries, people were working on that, but I don't know what the progress of that is right now.

So is Julia a good candidate for the distributed computing or are there other languages? Oh, you know, so there has been work on distributed computing in Julia, but the work that I was doing was more to do with parallelization on a single machine. Now, I did have colleagues who were working on building on some of the tools that we developed to do large-scale data parallel cluster computing with Julia. And so, that's yet another aspect of distributed computing. So you mentioned a sort of sensor network setting, and then I was talking about things like consensus algorithms. Then there's large-scale data-intensive cluster computing, which is yet another facet of distributed computing. So yeah, I think there's a lot of work being done in the Julia community on that sort of thing.

And when you say cluster computing, I remember the old SETI at home, where it would send you a little bit of data and you would look for signals. Is that what you, I mean, clearly much more advanced than that, but is that the right cluster computing mental model? So by cluster computing, I mean, you have some massive data set, and you're computing usually in a data center, as opposed to on individual machines. You're breaking the problem up so that lots of smaller processors can work on it. Sure. Yeah.

Okay. So back to this seminar. Yeah. It seemed like a lot of it was about how to read a technical paper. Right, right. Yeah. So the students taking the class are all in their first or second, I think maybe one third year student. And so they're all PhD students. And part of the goal of doing a PhD, especially at the beginning, is to develop the tools to become well-versed in a research area. So part of that involves reading a lot of papers. And reading papers is a skill that you learn. Nobody just shows up knowing how to do it. So, part of the point of taking courses like this

is to read a bunch of papers so that you learn what a paper is, and then eventually you get better at reading papers, and eventually you write papers. Why? I mean, I read a lot, but I don't read a lot of scientific papers because they're very hard to read. Yeah, yeah. Why don't they make them easier to read? Yeah, you know, so I was talking to somebody recently about scientific communication, and my friend was telling me that, oh, well, you know, scientists are never taught how to communicate. And I was thinking about this, and I thought, well, actually, there was a lot of communication training in my graduate training, but it was all about how to communicate with other scientists. Which was a really specific kind of communication. And so, these papers are

written for other, not only just for other scientists to read, but for other scientists in your area to read. And not only that, but even within a given area, it's often very hard for two people who aren't in the same laser-focused little subfield to understand each other's work. I go to conferences in my area, programming languages, all the time where I don't understand at least half of what is being said. And most of the other people there would say so too. And one thing that I want my students to realize and get used to is this feeling of being comfortable with being uncomfortable, right? Like, you have to realize that there's not time. You're not ever going to be able to understand everything. And you're not

ever going to understand this work as well as the author understands it, but you can learn how to read it in a way that you can glean what you need from it. And that's a particular way of reading. It doesn't necessarily mean that you can plow through the paper from beginning to end, and every time you get to something you don't understand, you must stop and stare at that sentence until you understand it. Sometimes that's the wrong way to approach things. Sometimes you have to read in a different way that will allow you to still make progress, maybe without understanding every tiny detail. And then when it comes to the point where you do need to understand a detail, well, then you can focus on that particular section,

and maybe you can communicate with the author and so on. But really, I mean, the paper is just the beginning, right? Like, you aren't necessarily expected to get all the information you need from the paper alone. The paper is a snapshot of what a given piece of work was like at a given time. And then once you get the idea that that snapshot might be interesting to you, well, maybe then you should have a conversation with the author, or you should go to a conference where similar work is being presented. And it's only by doing all of these things, reading and talking to people and going to conferences, that you eventually develop the kind of detailed understanding that you really need. And then you write papers like that.

Yeah, and then you write papers, which, you know, if you're lucky, other people will care about them and read them. You know, I think what you're getting at is that, you know, kind of once people get trained in this sort of way of writing papers, that if they read a lot of unapproachable and dense papers, then if they read a lot of unapproachable and dense papers, then they are eventually going to produce unapproachable and dense papers themselves, right? And, you know, I hope that it's not always that way. And as I mentioned, papers are only one way of communicating, right? Sure, you know, papers might be really dense, but we can also communicate in other ways. One of the things that my students are doing this quarter is writing blog posts about

the topic of the course. So, I'm asking the students to write these posts so they learn how to communicate not only with each other, but also with a general technical audience. So, hopefully in the next couple of weeks, we're going to be putting up our first few blog posts. And the students have some really interesting topics planned, which I can't wait to share with the world. I appreciate that because I do sometimes want to learn things from papers. And I mean, I've read enough, I've written a few, but it isn't something that's easy for me. I'm not fluent in it. And yet, I think there are things

from the academic community that the industry could use more. And I wish there was more communication between them. Yeah. Yeah. Well, I am blown away that anybody who's, for whom it's not their job to read papers is actually reading papers. I didn't read papers before I went to grad school. And I, you know, as a grad student, it's your job. And as an academic now, it's my job. So it's what I actually get paid to do. And when people do it as a hobby, that amazes me. I really admire that. I don't really read papers in my free time. I mean, I guess you could argue about whether or not I have free time. But for me, I mean, it's a job that I love, but it's still a job. So I'm really impressed by people who work a full-time job and then take the time to read academic papers recreationally on top of that. Me too, and I didn't mean to imply I was one of them. Yeah, every time I've had to read them has either been for school or for work. And like you were saying, I think there's a vast body of things that's in the literature that engineers don't know about because they don't read academic papers.

And so there's solutions to problems that companies are doing that are just out there and people don't know about them because they just try to invent it within the company. It's easier to invent it yourself than to read about it, which is so sad. There was at least a couple times where some papers helped what I was doing immensely. It took months for me to kind of be able to read them and apply them. And I actually had to. Yeah, you had a professor. I had to hoodwink a professor to come talk to our company to talk to help us through it decipher yeah so i think that there's also uh there's a uh what's the word uh a case of um misaligned incentives

where in order to publish a paper it has to to be novel. So, it has to be sufficiently novel over what's been done before. So, it's really hard to publish a paper that just takes work that has been done before but explained poorly and explain it well because that's not considered novel enough to publish. Now, a lot of people still do that and they may or may not publish it. Or maybe, you know, once they're secure in their career and they don't necessarily feel the need to get lots of publications, maybe they devote themselves at that point to being able to explain their work or other people's work better, which is an incredibly valuable service to the community. But until you get to that stage, then it's very hard to devote

time to really explaining things properly because you're supposed to be doing new poorly explained work. And now I feel like I understand your job as a new professor a little better. It's also really interesting to look back at old classic papers. And so you mentioned, so one of the papers that we read for the course is this classic paper from 1978, Time Clocks and the Ordering of Events in a Distributed System by Leslie Lamport. So, this paper is really interesting because parts of it are not at all interesting or relevant to us today. And other parts of it are extremely interesting and relevant. But at the time, it's not as though he could predict the future and know

which parts of this paper were going to become relevant. And this is the case for almost any classic paper that you look at. A lot of it is going to turn out to be irrelevant. And it's only particular parts of it that end up being the important parts. So, as you're reading any given paper, you should realize even the papers that are considered the classics, like the pinnacles of the literature, they're maybe only like 50% relevant, maybe only 50% good. And for any given paper that you might read, it might only be like 10% good. And so if it doesn't make any sense to you, maybe it just doesn't make any sense. And it's not your fault. I like that as inspiration, but I feel like it's going to encourage me to continue skimming and not understanding. But you mentioned your free time.

Mm. And so I guess in your free time, you organize conferences? Yeah, I seem to have fallen into that trap. Yeah, so for the last five years now, so Bang Bang Con started in 2014. And it was started by, I guess I can tell you a little bit about the history. It was started by a group of people who are all affiliated with an organization called the Recurse Center in New York, which is a retreat for people to go and become better programmers. And so I'll just throw in a plug for the Recurse Center. So it's for anyone with any amount of programming experience. There are people there who have been programming for 30 years.

There are people there who have been programming for six months. There are people there who have been programming for six months. And you can work on whatever you want there. There's no curriculum. So it's – and it's free also. So they make money by helping people who attend get jobs afterward. So they charge a recruiting fee to companies that employ people who attended there. But it's not a boot camp in the sense that there's no curriculum and there's no – it's not necessarily for beginners, although beginners are welcome. It should be thought of as more like a writer's workshop for programmers.

So I met a lot of really interesting people through my affiliation with the Recurse Center. I did a couple of residencies there in 2013 and 2014. And at one point, people were sitting around talking on the Recurse Center chat system about traveling to New York to attend their annual reunion, which they called Never Graduate Week. And so, this person was kind of lamenting the fact that he didn't have a good excuse to come to New York to come to the reunion. And somebody joked that he ought to make up a fake conference and say that he was speaking at it and then go. And then somebody pointed out that, well, this was, I think, February at the time, February of 2014, and the Never Graduate Week reunion was planned for May. And somebody pointed out that in that much time, they could actually plan a real conference. And one thing led to another. And then this group of people decided to actually put on a

conference. And so this conference, which originally, like the original idea was just a joke, ended up being a real conference and being successful beyond anything that we had imagined. And so we kept doing it the next year and the next and the next, and it grew and grew. So that first year, there were only 100 attendees, but it was still the format that we had for it was that we figured out that first year is kind of what we kept for the next five years. So the format was one weekend, all lightning talks, except for two keynote talks, one on each day. And everybody gets up and talks for 10 minutes about something that excites and surprises them about programming and computing. And we required that every talk had at least one exclamation point in

the title. So the idea of BangBangCon is to get people to talk about something that really excites them. And I always say that if you are interested in something and it's just a little bit too weird for a typical tech conference, then it might be perfect for BingBingCon. Something that excites them that's important important i was giving a lot of conference talks and i enjoy speaking and i enjoy sharing knowledge and meeting people yeah but i ended up giving a talk changing the topic at the last minute because there was something i was excited about and giving a talk that i really really had just had so much fun and just loved. And now I can't give talks because I only want to talk about things I really care about. It was such a better

experience for me and it was such a better experience for the audience. And it's now almost impossible for me to talk about anything that I don't passionately want to talk about. Well, you should submit a talk to BangBangCon about something that you passionately want to talk about. So submissions are starting soon. Yeah. So yeah, thanks for bringing this up. So let me add the last bit of the history. So BangBangCon happened in New York for five years, has happened in New York for five years, presumably will continue in New York. So I've been here on the West Coast now for a little while, and I was traveling back to New York to go to the conferences. And this has gotten harder and harder to do as I've had a child, and

then now that I've started this new job, and for a long time, we've thought that we've needed to expand Bing Bing Con. So these different forces in my life of wanting to be here on the West Coast and wanting to expand Bing Bing Con kind of came together. And my longtime Bing Bing Con co-organizer, Maggie, Joe, and I decided to put out a call for volunteers to start a version of Bang Bang Con here on the West Coast in Santa Cruz, which we would call Bang Bang Con West. And so, we, over the summer, called for volunteers. We had 25 people agree to volunteer. And, well, okay, we had 25 people offer to help organize. Out of those, we ended up narrowing it down to, I think, 10. And those people are now the organizing team for BangBangCon West. And we have a fantastic team. Some of them are people who attended or spoke at BangBangCon on the East Coast, others are not. And another part of the motivation for us wanting to start this new version of BangBangCon is that, so things were kind of, on the West Coast, you know, we were, or rather on the East Coast, we'd had kind of the same organizing team. And we'd added some new people over the years, but it had kind of gotten to be the same group of people.

And starting this new version of the conference gave us an opportunity to inject a whole bunch of new ideas and new blood. And so the new organizing team does things in a way that we wouldn't have necessarily done things before. And that's good because we really needed that shot in the arm to start to do things differently. And not only that, but a lot of these people are motivated to go on and start their own conferences when this is done. So, you know, what we found with BangBangCon is that we just can't serve all the people that we want to serve. We get way more talk proposals than we can possibly accept,

way more good ones than we can possibly accept, way more good ones than we can possibly accept. We always run out of tickets within a matter of minutes because we can't accommodate all the people that we want to accommodate. And I think that the only real solution to this is to distribute Bang Bang Con and have a Bang Bang Con in every city. And so part of the goal of this is, of having this West Coast version of BingBingCon is to kind of serve as an experiment substrate for people who want to learn how to organize a conference.

And then after we're done, each of those people can go out and start their own conferences elsewhere if they want to. Cool. And now back to the question. So what was the question again? Speaker proposals. Right. Yeah. So we are opening our call for proposals today.

We just spent the last week scrambling to get our website ready to go. And is that today, the day the show airs or today, today? Yeah. So, today, today. So, by the time this show airs, it will absolutely be open. Okay. And what does the call for proposals look like? I mean, I have to put down my name and my title. Yeah. So, what we're asking for is a title for the talk, which has to include at least one exclamation point. Can it include more? Yeah, absolutely. It's Bang Bang. You can have at least two. And I heard it was originally called Bang Bang Bang Con, so three is still acceptable.

Yeah, yeah. So the name was actually inspired by Julia Evans' blog. So I think you've had Julia Evans as a guest here before. Yeah, so if you know anything about Julia's writing style, there are a lot of exclamation points involved. Julia was one of the original founders of Bang Bang Con. And somebody joked that we should have a conference called Julia Evans Blog Posts Con. And then this got abbreviated to Bang, bang, bang con. And then finally to bang, bang con. And that's the name that stuck. Uh, so that's the history of the name. The name is, I have, I have some amount of regrets about the name because it's, uh, it's hard to

explain to people and, uh, it's hard to Google for, but it's stuck and it's our brand now. So now we have to live with it. So, yeah. So when you submit a talk proposal to BangBangCon West, so you'll have a title for your talk, an abstract for your talk, which is just a few sentences about what you plan to say. We also ask people to submit a timeline because every talk is only 10 minutes. So you have to have some idea of how you're going to use that very small amount of time. And so a timeline is kind of a minute by minute or couple minute by couple minute outline of what you plan to say.

And we have some examples of outlines that you can look at. We also ask for you to specify what kind of background your audience would need for them to be able to get something out of your talk. And this isn't, we're not going to rule out a talk necessarily on the basis of needing to have a lot of background, but that's more just for us to calibrate. Like, so for example, if somebody submits a talk proposal and we don't understand what it's about, and then for the background they say no background required, then that's a sign that the talk proposer isn't necessarily thinking very clearly about what kind of background the talk would require. So it's not that we don't,

it's not that we are asking people to necessarily submit beginner level talks, but we just want every speaker to be aware of the background that the talk that they're submitting would require. Speaking to an audience that you understand is so much better. Yeah. Yeah. And so I guess our theory with BangBangCon is that because the talks are only 10 minutes, almost everybody has the ability to be interested in something for 10 minutes. And because you only have 10 minutes, there isn't necessarily the opportunity to go into the weeds on a topic.

Although we do actually really like talks that dig deeply into a topic. So sometimes somebody will submit a talk proposal and it'll be way, way too broadly scoped. So for example, if you submitted a talk proposal and it was called the basics of embedded systems. Yeah, exactly. Or I was just going to say embedded systems and why I like them, you know, exclamation point. That would be a bad talk proposal because it's way too broad, but a great talk proposal would be, here's this really weird bug that I was working on last week and how I figured out how to fix it. Okay. All right. So not bootloaders. No. So every now and then we do get a talk proposal that is kind of more broadly scoped. And usually when those work, it's because the speaker finds some kind of angle that will make

it work in the 10 minutes. So we've had, so for example, we've had some talks in the past that were about time and computing, which is an incredibly broad topic. Never work on time. Never work on time. So, that's a topic that obviously there's way more than 10 minutes of stuff worth to say about. But the speaker found a particular angle that made it work. But for the most part, we like it when talks are really focused and we like storytelling.

So if you have a story and, you know, you want to make it personal, right? You want to, you want to say something like you were saying that, that it's so much easier to give a talk when it's something that you personally care about. We like it when people give talks where that person speaking is the only person who could have given that talk because they're talking about something that um somebody will submit a talk proposal and it will be as though it's just the uh it's just a talk proposal that they would have submitted to any

other conference except they stuck an exclamation point on the end of the title and that's not really going to fly at bang bang con because for one thing um you can't necessarily fit your 40 minute talk from another conference into our 10 minute talk slots um but for another thing it's just it's not uh it's not the right fit topic wise uh like we're we're looking for we're we really are looking for personal stories we're looking at what brings you joy, excitement, and surprise in the world of computing. And if you plan to get up and talk about something, I mean, you can say, here's a topic that you might have thought was dry and boring, but it's not dry and boring, and let me tell you why. And that could be really cool for BingBingCon.

But if the talk is more like, I'm going to tell you how to use this particular tool that will help you be more productive in your job, that sounds boring. Nobody comes to BingBingCon to learn how to be more productive in their job, although they might end up learning things that will make them more productive in their job. They come to Bing Bing Con to relax and be refreshed and be inspired. So that's the kind of talk proposal that we're looking for, the kind that will inspire people and refresh them and excite them. And do you get slides if you're a speaker? Yeah. So speakers have the choice of using

whatever kind of presentation medium they want. So most people present slides, but we've had some really unusual choices too. So for example, we had a speaker a couple of years ago who was demonstrating how he uses his screen reader and so uh his talk was mostly a tour of what it's like to use his computer and his phone uh interacting with them uh via screen reading tools which were reading to him at hundreds of words per minute. So for that particular talk, the audio was the most important component. It seems like with many conferences, the switching between talks is tedious and long.

Given how often you're switching between talks, how do you make that not a problem? Yeah, we do our best. So we have sessions that have four or five talks in them each. And everybody who's speaking in a session comes up beforehand to do an AV check. So we try to make sure that the changeovers will be fast. And every once in a while we have some technical difficulties, but that's to be expected when you have such a large number of speakers and so many different kinds of computers and so many different ways of presenting. I think the biggest technical difficulties that I've seen at BangBangCon were when somebody brought their own Apple II from childhood and hooked it up and live coded on it. So we made it work. Yeah, but it wouldn't be easy.

Yeah. And, you know, we actually made it work. And it ended up being one of the best Bing Bing Con talks that I've seen. And it was a huge audience favorite too, but it did take a lot of effort and we have an awesome AV team that has a lot of experience in solving these kinds of problems. Cool. So as an organizer, what's it like organizing this conference? So, you know, I've learned a lot about conference organizing in the last five years of doing this. And I think the most important thing that I've learned is that being able to trust your colleagues is incredibly important. And I would say that at first, when we first got started, we didn't necessarily trust each other and we didn't necessarily trust ourselves. So, for anything to get done, everybody had to discuss it endlessly and we had to get consensus with the whole group. And yeah, it was rough. So so as time went by and we began to trust each

other more and understand each other more and know more of what we were trying to do we got better at what we were doing and so the taking the risk to kind of throw aside all of that context and history that we developed as a group and start Bing Bing Con West with a whole new group of people was risky in certain ways because we didn't necessarily trust each other yet. But that's why we went through this process of asking people to apply to become organizers. And being an organizer of a conference is really grunt work, right? It really is. It's a lot of grunt work. And we didn't know if people would sign up. And so when 25 people did apply, we were pleasantly surprised. So that shows,

that says to me something about how much people care about this conference and how much they wanted to bring it here to the West Coast. So the people that Maggie and I ended up asking to join us and the group that we ended up getting were a group of people who we thought would cohere and that we thought would be able to trust each other or develop that trust in each other. And I think the group's been doing a great job so far. And I've been super impressed.

So I've been trying to hang back and not do so much because, you know, for one thing, I only have so much time, but also part of the goal here is to get the new crew of organizers to become great at conference organizing so they can go do this more in the future if they want to. And so I've been super impressed by, they've been introducing all kinds of process into things that we never had before. For example, in the past for choosing keynote speakers, we just kind of brainstormed some names and then we kind of came to a rough consensus and then we'd invite some people. And this year instead,

the new organizers developed a process that involved proposals and voting and allocating certain numbers of votes to different possible speaker slates. And at first I thought, oh, this is way too much process. But then I realized this isn't my decision to make. This is their conference. It's not my conference. And the results ended up being awesome. And we now have two really great keynote speakers that we're almost ready to announce. And I'm so excited that the process worked so well and that I didn't butt in and tell them they were doing it wrong because the results ended up being amazing. So, yeah, so that's an example of, you know, you always have to tell yourself,

like when somebody's doing things in a way that's differently from how you would have done it, you have to ask yourself, well, are they doing things in a way that's wrong or are they just doing things in a way that's different? And if the answer is it's not wrong, it's just different, then you have to be okay with that. And so developing that trust in people and letting them do it their way, which is a perfectly good way and in fact better maybe than the way that I would have done things, that being able to have that trust is really important. Delegation is a skill that requires practice. It's so easy to go back and say, oh, no, no, no, you should have done it this way. But you can be surprised by the results and thrilled with them. Yeah.

And especially if we want Bing Bing Con to eventually scale and for there to be a Bing Bing Con in every city. You know, some of these conferences are not going to be run in the way that I would have chosen, and that's okay. There are actually already a couple of conferences out there that are inspired by BangBangCon, but that do things in their own way. There's one now in Canada called StarCon, which was started by a group of students at University of Waterloo, all three undergrad women who started this conference. And they have done an amazing job. And I've been incredibly impressed and they're now in their second year. But they do some things differently than BangBangCon. For example,

their talks are 15 minutes long instead of 10. And that's an intentional choice that they made because that's what they want. And that way of doing things is not wrong. It's how they want to do it. And likewise, there are going to be other conferences that do things, you know, maybe sort of the Bing Bing Con-ish way and maybe not. And part of the goal of bringing in all these new organizers was for them to point out flaws in the way that we used to do things so that we can try to do better. I've noticed that some of the talks from previous Bang Bang Kongs are videotaped. And there's this idea of online conferences now. Where do you fall between the smallish local conference and the big online conference spectrum? Mm-hmm. confronting issues of climate change and wanting to ask people to travel less so that they don't

have to fly so much. Asking people to go to fewer conferences throws a huge wrench in the process of scientific communication that I was talking about before. So what can you do to fix it? Well, one thing that you can do is have live streaming of talks, and BangBangCon does that. So there are recordings, but also the talks are all live streamed. So people who aren't there in person can still interact in real time with other people who are watching the talks. And conferences in my professional community have started doing this too. So, for example, I just came back from ICFP, which was in St. Louis in September, which is the International Conference on Functional Programming. And talks were live streamed.

And also the Q&A was done online so that people who were watching on the live stream could ask a question. And then those questions would be upvoted. And whoever was chairing the session in which the speaker was speaking would then choose what questions to ask. So this gave people a way to participate whether or not they were there in person. And people who were in the room as well could use the online Q&A tool, which even if you are there in person, that can make it a lot easier to ask a question if you have the opportunity to write your question down. And then sometimes questions that might not necessarily have been asked will rise to the top in the question voting. And so it ends up being a better experience for a lot of people. But those kinds of tools can also help enable remote conference attendance. How many hours would it take to organize a conference of 70 people?

Oh, you know, I don't know if the number of people attending is really the right scaling factor. Okay, what is? I don't know. I mean, so for BangB bang bang con we started out and we had 100 people and then 200 and then 300 and i would say that growing the number of people uh didn't make a huge difference in the amount of time it took to organize it was still the same number of talks uh things that did make a difference in the organizing effort included things like whether or not, well, so one reason why a number of people would make a difference is what kind of space you can use. So in our first year, we used the space that was offered to us by the Recurse Center, which was free and available. And so that was a lot easier than trying to go out and find a space.

But it was also really crowded. And we were tripping over ourselves in the space and having to pile up furniture on top of other furniture in order to make room for all those people. So that wasn't sustainable. And then we went out and found spaces. And then over the last couple of years in New York, we've had this great relationship with a company called AppNexus, which has their own auditorium within their office that they let BankBankCon use. And so that's fantastic. For this conference, we have space that's provided to us by UC Santa Cruz. So that's great.

But we still have to deal with issues of food and transportation and so forth. Did you look at other venues in Santa Cruz? We decided to do it at UCSC because this was actually part of my process in negotiating when I accepted the job was that the university would help sponsor the conference. And so they're providing some financial and logistical support for us, which is awesome. But part of that was that we agreed to have the conference on campus. And so I think the campus is a great place to do it. It's a beautiful campus. It's a beautiful campus. And I think the values of the university and I have aligned with the values of BangBangCon in certain ways. And so that works out well but uh it's also kind of weird to have it in santa cruz

at all and especially at uc santa cruz after all these years of having it in the middle of manhattan because yeah we are even in downtown silicon valley area we are kind of outside. People will travel in order to get to spend the night. Right, yeah. So, that makes it a different kind of conference. And that's something that we all were aware of when we came into this, and we knew that that would change the flavor of the conference. And so, you know, that's hard to avoid, right? Like doing the conference in a different place, place matters, right? Like, uh, having the conference in Manhattan meant that people could get there on subway and we didn't have any kind of, um, well, we had a, we had a webpage that said, you know, here's the subway lines that you can take to get to the conference and here's what stop you should get off at. And, um, all right, you're on your own

with this. It's going to have to be very different. So with bang bang con west, uh, we're, uh, we have plans for transportation that are much more involved. Um are we're still working out the details but it's that's that's going to be one aspect of organizing the conference i think the the place that you decide to have the conference and the um the logistics that are involved in that are you know you asked what takes time in organizing a conference. And I think dealing with that stuff could take a lot of time or a little time depending on the particulars. I mean, the good news is there's parking nearby and most maps can find the building. The bad news is once you get there, all the buildings look alike. Yeah. I mean, but just the fact that you bring up parking at all,

right? So in Manhattan, it would have been ridiculous to think that anyone would drive to the conference whereas it's going to be ridiculous to think anybody won't drive to the conference right so but one one thing that we might do is figure out uh carpooling or vanpooling or a bus so that people don't necessarily have to drive to the conference because we don't want to expect that everybody is able to do that. So that's going to be an important aspect of organizing this year that we never had to think about before. Since you're on a college campus, do you think you'll be getting a lot more students? I hope we get students. But I also expect that registration is going to sell out really fast, as it has in BangBangCon's past. So, now, I don't necessarily want to assume that that'll happen, because we're dealing with a ticket through the regular process will depend on who's on the ball enough on the day that tickets go on sale.

Now, the best way to make sure that you get a ticket to BingBingCon, of course, is to give a talk at BingBingCon. So that's, and I hope that we do get a lot of students submitting talk proposals. I've already been talking to a bunch of students about it who seem excited. So, yeah, I expect that we're going to have at least some students giving talks and attending. And then I hope that we can also set aside some tickets for groups of people who I think would be interested in the conference but might not have otherwise had access to it. So, whether that means students or other people from the community, we're still working out the details. But yeah, one way or another, I expect that there will be some students there. Cool. Well, I know we only have you for a limited time. So, let me see, Christopher,

do you have any questions? I had one question that I meant to ask a few minutes ago when it was you for a limited time. So let me see, Christopher, do you have any questions? I had one question that I meant to ask a few minutes ago when it was more relevant at the time. We'll go back in topic history. So 10 minute talks. I used to be afraid of talking for five minutes when I was a sixth grader. But when I gave more and more talks, it got easier and easier. And to the point of, I can't imagine giving a talk for only 10 minutes. That sounds like I'd be able to read my title

and then I'd be done. It's much easier to talk for an hour. Do you provide any coaching or resources for people who might have given talks in the past and like, well, here's how you can do a tight 10-minute talk? Just talk faster, right? That's my strategy. You know, we have had some speakers who get up and speak really, really fast.

And I should mention that at BangBangCon, we've always had a professional stenographer who is transcribing the talks live. And we've had some people, even though our stenographers have always been amazing, we've had some people who speak so fast that they really provide challenge. I'm just going to give an hour talk. I'll do it in 10 minutes. Right, right. But, yeah, so, but to your question, yeah, it is really hard to give a 10-minute talk. And my best advice to somebody who wants to give a to give a talk but thinks i can't possibly fit everything that i want to say into 10 minutes uh i would suggest uh going and watching a bunch of

the existing bing bing con talks and seeing what's there and think about no this is the reason why we ask people to give a timeline uh and i have a blog post which is linked from our call for proposals which will go up soon that gives some examples examples of good BangBangCon timelines. It also has some examples of bad timelines in case you want to know what not to do. The first five minutes I'm going to introduce me, my company, my blog, my podcast, my parents. We've had people say, so we've had them say things like, um, minute one introduction, introduction next eight minutes body of talk last minute conclusion it's like that didn't tell us anything that's aspirational more than

description right right and then there are people who just ignore the fact that there is a 10 minute time limit and then they give a timeline that adds up to way more than 10 minutes. So those ones always get rejected too, because it's a reading comprehension failure. But yeah, so, but coming up with a timeline is, you know, we want to see it, but it's also a tool for you, the person proposing the talk to try to figure out, okay, what exactly can I fit in into 10 minutes? And sometimes you'd be surprised how much people really do manage to fit into a 10-minute talk. Well, I am looking forward to attending, assuming I get a ticket. And I think it's a neat thing to do to bring this conference that I've always wanted to go to here, and I'm excited about it.

Well, I'm so happy to hear that you have always wanted to go, and we would love to have you there. I should mention one other thing is that we're also looking for sponsors. And this is one way for an organization to get tickets, which is that if you sponsor us at a certain level, we can provide some sponsor tickets along with that. So I don't have the exact levels and numbers available right now, but that information will be on our website at bingbingcon.com slash west. We do have some Patreon money left over.

All right. Well, I think we should end it there. Do you have any thoughts you'd like to leave us with, Lindsay? Submit lots of talk proposals to BingBingConWest. And if you're interested in programming languages and distributed computing, come and do a PhD with me at UCSC. Our guest has been Lindsay Cooper, Professor of Computer Science and Engineering at the University of California, Santa Cruz. Go Banana Slugs. Thank you for being with us. Thank you.

Thank you also to Christopher for producing and co-hosting. And of course, thank you for listening. You can always contact us at show at embedded.fm or hit the contact link on embedded.fm. Go there for the show notes and we'll have a link to that. Bang Bang Kong West, as well as Lindsay's very interesting blog, composition.al? Yeah. And whatever else I think we should have. And now a quote to leave you with. So we talked a little bit about this Leslie Lamport article from 1978.

And I thought it was very relevant because I've been working on a distributed system with some time issues. So let me just take a little quote from that. Most people would probably say that an event A happened before an event B. If A happened at an earlier time than B, they might justify this definition in terms of physical theories of time. However, if a system is to meet a specification correctly, then that specification must be given in terms... What the hell? Yeah, it goes on like that for a while. So yeah, papers, they're hard. Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of

Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show, we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.