All right, should we go ahead and get started? All right, sounds good. OK, hello, everybody. Thank you for taking the time to come join this session today. My name is John Chan. I am a engineer at Stack Overflow. And today I'm going to be talking to you about building a remote engineering culture. Before we actually get started, a show of hands, how many of you are developers here? Or code. Oh, very good. So I'm assuming most of you know what Stack Overflow is. Yes? If you don't and you're an engineer, you probably should find out because it'll help you a lot. How many of you are hiring managers? Any of you? How many of you think about recruiting engineers? OK. And one last show of hands, how many of you work at a company that is at least partly remote? That means there's somebody full time that is working remotely. All right, good. There's a good, decent number of you. All right, so let's get started here. Oh, there we go. OK, now I can just start it. All right, let's get started. So a little bit more about me. This is my TLDR. So like I said before, I've been working at Stack Overflow. I am what is called the marketing engineering lead. That means I lead a team of engineers, designers, as well as marketers, thinking really about growth and re-engagement across the company and what people really think of the Stack Overflow brand. Another thing that I want to mention is that I'm also the founder of Bento. And I think a lot about tech education and how to democratize learning how to code for pretty much all people. And the other things that I sort of want to mention here too, I'm also the head of diversity and inclusion partnerships at Stack Overflow, and also the creator of Descartes.io. So with all of these different things, I'm going to be drawing on my experiences, thinking about how to build engineering teams, and also thinking about how we can continue to do engineering in a way that's distributed. So we're going to be talking mostly about three things today. The first is really why remote. So we really believe at Stack Overflow that remote work is the future of talent. There are so many different advantages to having a remote team, and I'm going to be going over a few of them with you today. Two is how we do it. At Stack Overflow, we really think that remote is part of our DNA. There are a lot of different things that we do to make remote possible from the very beginning of Stack Overflow, and I'm going to share a few of those ideas with you here as well. And the last thing is more of a shift here, and that's really about something that I call extreme remote. So I've personally taken our remote policy at Stack Overflow to an extreme, and I'll give you a look into what it's like to be nomadic at Stack Overflow. That means traveling full-time while I'm working at Stack Overflow full-time as an engineer. So I'll give you a peek of what that's been like too. At the very end, we'll have five minutes for questions, and of course, if you have any more questions afterwards, I'll be telling you how to get in touch with me, and I'll be sticking around for the conference for more questions if you have them. All right, let's dive in. So first, why remote? So when it comes to remote work, there's really two things that really boil this down to. There's a lot of different advantages to being remote, but it really comes down to two things in my mind. The first is really when it comes down to talent. You know, having a remote workforce really gives you access to really amazing talent. And the other thing, the other half of that coin here is that it also makes your workforce resilient to change, and I'll tell you more about what that means in a bit. The second thing that I wanna highlight here is around productivity. You know, one of the big myths about remote work and actually having a remote engineering culture is that it's not productive. How can you be productive if you're not altogether sitting at the same place? Well, we actually think that when remote is done well, it can actually make you more productive as an engineering team. And it really comes down to flexibility and autonomy. And those two things in combination will really enable your remote workforce to be really productive. There's two references here, two blog posts that I wanna mention. The first is on working remotely, and this really talks about the origins of our remote sort of culture from one of our co-founders, Jeff Atwood. And the other one is why we still believe in working remotely. It's sort of as a follow up to that blog post by our VP of engineering, David Fullerton. So if you wanna find out more about these topics later on, I'm gonna be distributing these slides later. Go ahead and take a look at those blog posts. So the first thing, one of the two things that I was mentioning, first is talent. So the first thing, and I think a lot of you, especially the ones that have sort of raised their hands about hiring engineering, engineering talent is really rare. At Stack Overflow, we do a lot of research about understanding what the developer landscape is like. And what we find is that there's only one programmer for every five jobs that exists. There aren't enough programmers to fill all the jobs, including the ones that you have open positions for. And that means that it's a really, really competitive landscape when it comes to hiring engineering talent. So what you wanna do if you wanna be remote is that you can help diffuse the competition.  If you start thinking about hiring remotely, you can dramatically increase that pool if you want. Now the other side of that coin, right? And in addition to sort of expanding your pool, is that it's really great for the individuals too. You can get access to a lot of untapped talent. There is amazing engineering talent in areas where you probably wouldn't think would be a great place to actually be an engineer. Because, you know, not every place is San Francisco and Silicon Valley and New York City and Singapore and all these different places where there is a concentration of jobs, you would be missing out on all the engineering talent if you only restricted yourself to those physical locations. So being that opportunity for those people in those more remote areas is gonna be huge. It gives you a huge competitive advantage to actually getting that talent. Now the last thing here is that it helps you be resilient to change. How many of you know somebody that has to change a job because either their spouse had to move or they had to move back to family? Anybody? Right. So imagine, you know, if you were in a really good job, a great engineering team and suddenly you had to move back because of family or something else, being in a remote engineering culture means that you don't have to leave your job. So it makes your workforce really resilient to change as well. So this second half of this, productivity. We really think that the productivity here, especially when it comes to the individual and remote teams, comes down to flexibility and that translates into high-performing teams. So being remote, that means that you give people the ability to optimize how they can be productive as an engineer. You really give them the flexibility to figure out when can I be most productive. Now one of those things that we think is going to make engineers really productive is this idea of a private office. How many people sort of work in an open space in an engineering room like Cubicles? Sometimes it's a little hard to concentrate, right? So you sort of hear people in the background and you end up putting headphones on and then you just blast music. That doesn't really help a lot. But what's really nice about being remote is that you automatically get a really nice private office. It's at your home. We really think and really believe that programmers need uninterrupted time periods so that they can concentrate and work on code. Having a private office being your home is really, really helpful if you're in a remote culture. The other thing here, too, is that your time is better spent. Remote means that you get a really, really short commute. That means you just roll out of bed and start working if you want to. And the other really nice thing there, too, is that you get flexible hours. You get a lot more control over when you actually work and figure out when you are most productive, when you get to work remotely and not be tied to a desk that you have to get in at nine and leave at five. And the last thing here, and this is more from the management perspective, but that helps you, it forces managers to think about managing towards results as opposed to what we call butts and chairs. It's really easy to delude yourself into thinking that as long as you're spending eight hours a day that you're actually getting work done. It's probably no secret to anybody that if you're spending all that time in an office, maybe some of that time is spent on Reddit or Hacker News or something else like that and not necessarily coding all the time. So instead of trying to force and think about productivity as being something where it's just people putting in time, you can think and really focus on results instead. So really when it comes down to it, why remote? Remote is flexibility. That's really what the really big advantages here are, not just for hiring managers and people looking to build engineering teams, but also when it comes to trying to make your engineering teams really productive, too. So how do we do it at Stack Overflow? First, before we actually dive in it then, I wanna give a little bit more background onto what Stack Overflow is like. The first thing is that we're pretty big and we're kind of everywhere. We're just at around 300 people with our three physical office locations in New York City, in Denver, both in the United States and in London and the UK. Overall, we are 25% remote. That's engineering, sales, marketing, everybody, but for engineering specifically, we are overwhelmingly remote. 70% of all of our engineering team is considered remote and that includes PMs, designers, SREs, and developers, too. The other thing here is that we're very, very much distributed across the entire world. We have people in Asia, we have people in Europe, in the United States, in South America. Pretty much every major continent that you can think of, we might have somebody or have some sort of presence there. The other thing that I wanna mention here is that we really started remote, too. Our co-founders, Jeff Atwood and Joel Spolsky, actually started the company on different parts of the country in the United States and our first few engineers were in different cities as well. Remote is something that we sort of began with and it's been part of our DNA ever since. So when it comes to how we do remote at Stack Overflow, these are the different things that we think about. The first is people, right? We really believe that remote is a people-centric problem. These are the things that we look for in people and how we set those people up for success in a remote work environment. The second thing that I wanna talk about is culture. So remote can only really be done well when everyone is bought into it. You know, what are the unspoken and sometimes the spoken rules about how to make remote work across the company when not necessarily somebody like a manager is there to enforce it. Making it part of the culture keeps everyone on the same playing field and the same level. And I'll talk more about that in a bit. The third part is about communication. And this is probably the thing that is talked about the most when it comes to remote is, well, how can you keep everybody informed about everything that they need to know if they're not in the same place?  So these are the different tools that we use and the philosophy that we take to communication. So let's dive in. The first of three parts is people. And we really think that finding and enabling people to be remote is the groundwork for that culture. I think that splits out into two major things here. The first is hiring and the second one is onboarding. When it comes to hiring, really think that you can hire for remote. And we want people to shift, they're thinking away from thinking about managing people that should be managed in a physical location and thinking about how to manage accountability and really focus on hiring right instead. Now the second part to that, once you actually get those right people, how do you actually set them up for success? And that really has a lot to do with onboarding. So onboarding is already difficult to do at any company, but remotely it's even harder. So setting people up for success remotely is extremely important and particularly important because there's a lot more culture and a lot more education to be done. So one of the references here that I sort of want to point out is Joel Spose's Guerrilla Guide to Interviewing. That'll give a lot of context about how we think about hiring developers and that'll also give you good insight into what we look for for developers overall, but also for things specifically related to remote. So hiring, hire instead of manage. It's really funny because whenever I talk to people about remote, especially other founders or people that are running engineering teams, one of the very first things that they think about is, well, I can't do remote because I need to make sure that I can keep people accountable for the work that they need to get done, right? What you might hear people say is that, well, I can't possibly have people, developers that are outside of the office because I need to be able to check up on them on a regular basis. And in many ways, when you're thinking about that and you're thinking of the questions around that issue, it's sort of the wrong question to be thinking about and when we think about it this way. So instead of thinking about this as a management problem, well, how do I make sure that I can keep people accountable when they're not in the office? You think about, are you getting the right people for the job and the positions that you want instead? You can't be looking over everyone's shoulder all the time. So instead, what we think that you need to do is that you have to try and find people that work well remotely. Now, what does that actually mean? When we think about remote, there's sort of two kinds of people that I think about. Sort of put yourself in this position. If you were going to be working from home, say, without anybody around you, none of your coworkers there, what would you end up doing?  Or there are some other kinds of people that would be really anxious if they didn't do anything, if they weren't being productive and they knew that they had to be. Those are, you know, you can put people somewhere on a spectrum on that. And what we're really looking for and what we think works really well for them out is trying to find those people in this category instead, the people that would be anxious if they weren't being productive when they knew that they needed to be, even when there's nobody else around them to tell them to do that. And the way that we sort of talk about that quality is that we say that those kinds of people get things done. Has anyone heard of this sort of phrase, smart and gets things done when it comes to hiring? Anyone? Alright, a few people. So, Joel Spolsky, our CEO, wrote a whole book about these two things and it's really the core of that blog post that I was referencing earlier is that when it comes to the way that we hire developers at Stack Overflow, it really boils down to those things. People that are smart and that they get things done. And when it comes to remote, it's really, really important that they get things done because what that means is that we're looking for people who are self-starters. People that are proactive. People that are entrepreneurial. The kind of people that would be anxious in a really lax environment where they didn't do anything. They want to be able to do things. What we notice when it comes to people that are working remotely is that we actually find that they work much more sometimes than the people that are actually in physical locations. And we actually screen for that kind of characteristic when it comes to those people that want to work remotely. Now, the last thing I will say here too is that we know we still also have physical offices. As I said before, not everybody works great in remote, but that doesn't also mean that we don't want them to, right? For those people who aren't great at remote, we also provide the option of them going into a physical location. I'm typically based out of our New York headquarters, but I also work remotely pretty regularly, especially when I'm traveling, like I am now. So it's really about letting people choose and supporting their decisions instead. So the second thing, onboarding. So now that you find those people, if you find the people that get things done, you really need to make sure that you set them up for success as well. It's not enough to sort of just hire them and then forget about them. Once you find those good people, you really need to educate them on the culture and really familiarize them with the tools. You need to make sure that the infrastructure and the culture is really there to help support those people that want to be remote. Now I'm going to mention a few things here. The really big thing here is called Stack University. So we have this onboarding program where all engineers go through. It takes about six to eight weeks and it really consists of a lot of different things, mostly three. The first is remote meetings. So this is when you sort of talk to each of the team leads on the engineering side, when you talk to people that understand different parts of the code base, pushing code. So we are trying to get every single engineer that comes to Stack Overflow to push code on their first day all the way to production. And they also work on what's called a graduation project where they actually take a feature that they want to prototype, work on it, do it for two weeks and then they actually demo it at the end to the rest of engineering. And the last, of course, is reading docs like you would see in a lot of other onboarding scenarios too. Now what's really interesting about Stack University is that we've also designed it so that it's completely remote and able to.  You actually can't do the onboarding without also being inundated in the culture. So the third part of this is also having a remote mentor. So when it comes to thinking about remote work, one of the really big things is understanding, well, how can I build relationships if I'm just alone in my house or traveling instead? So having a remote mentor, someone that can walk you through that first six to eight weeks is really important to us too because it gives you a first taste of what it's like to build a meaningful work relationship in a completely remote environment. And this is still the case also whether you're in a physical location or if you're in a remote location, there's really no difference here. Now the last thing here besides sort of the education portion of this is around equipment. We really, really believe that if you need something to get your job done, we will buy it, right? We wanna give you the best equipment that money can buy. Now every person that's at Stack Overflow that's remote, they get a headset so that you can have video calls just the way that anyone else would so that you're in a quiet environment. You get a standing desk, an ergonomic chair and you even get a high speed internet subsidy so that you get a home office that's very, very similar to the things that we would get in a physical location in New York, Denver or in London. We really wanna make sure that people feel as though they're on the same playing field and that they're really set up for success and things aren't getting in the way of making sure that they feel like they're part of the company even though they're not in a physical location. So this is really the big takeaway here. When it comes to thinking about people and remote it really starts with thinking about those people. It's really, really, really hard to try and do remote after their fact, right? It really needs to start with who are you letting into the door and how do you set them up for success so that they understand the culture and the education around all the things that we do when it comes to remote. All right, next, culture. What's the philosophy that drives remote here? And these are sort of the, when you talk about culture you sort of think about what are the rules that are sort of out there? The unspoken ones and even the ones that are repeated that make people do things in the absence of others. So culture is actually gonna be something that's really, really important to us when we think about remote. And again, there's two things here that I really wanna emphasize. The first is that everyone is remote. It's very important that we think of ourselves as a remote first company. It's really, really important that we make everyone feel like they're on the same level whether or not they're in a physical location or if they're remote instead. And the second thing about the culture here is that we really focus on empowerment. We really, really believe that it's important that you can do your work independently of many other people. Because if you really think about it, if you were dependent on a lot of other people to do your work, say that I can't push to production unless I have someone else actually take a look at it but you're in a different time zone from that and you have to wait five hours, that will make your cycles very, very slow. It'll make remote working a nightmare. So empowering those engineers is really key here. So one of the references that I wanna point out is a blog post that I wrote called Empowerment Organizations that really helps you think, sort of explains sort of how we think about empowerment when it comes to management and also how we think about empowering engineers as a whole. So if you're really interested in this topic, take a look at that in the future too. So let's start with everyone is remote. First is this idea of nobody on speaker.  How many of you have been in a meeting like that before or it dialed into a meeting like that? In that situation it's kind of weird because if you're on speakerphone or if you're on a conference instead, it doesn't feel like you're actually part of that conversation sometimes. It's a little bit strange. So at Stack Overflow we make sure that that feeling doesn't really exist anywhere. If you've had that experience, you feel like a second class citizen in those meetings. So what we do at Stack Overflow is that we use Google Hangouts for most of our video chats. And one of the things that we do is that even if you're in a physical location you need to go talk to somebody. What you'll end up doing is that you'll go back to your laptop, get on a video chat and the person right next to you will get onto a video chat too. The reason that is is because if you want to get somebody that's in Europe but you're both in the New York office, all you need to do is ping them and they can come back in to that chat room and start talking to you. And everyone feels like they're on the same playing field. No person regardless of whether they are in physical locations or if they are in actual remote locations feels that they are more advantaged or disadvantaged as a result of that. And that really applies as a philosophy across Stack Overflow when it comes to remote. How do we make people feel like they're on the same playing field? So one of the ways that we do that is also by creating virtual social spaces. So one of the things that we do or that people talk a lot about when it comes to remote is that, well, it must be really isolating to be remote instead. Well, how do you talk to other people? It must feel really lonely to be a remote worker. Now, one of the things that you sort of miss out when you sort of end up working from home or somewhere else is that you miss out on those casual social interactions that you'd get, right?  We have lunch every day in our offices at Stack Overflow. I'm not gonna be able to talk and go to different teams to chat about that stuff. So what we try to do as much as we can is that we have virtual social spaces too. Every week we have this thing called a Bev Bash, for example, where everyone can just sort of jump on a hangout and either grab a beer or coffee depending on what time zone that they're in and just chat. If you were just working and you didn't create those social spaces and all you did was meetings, you would actually end up still feeling that isolation. And there were also events and programs that we have on, we have this thing called Stack Roulette, for example, where we sort of randomize three people from across the company, regardless of where they are and get them talking to people. So you'll sometimes see a salesperson, a designer and an engineer on one call or you'll get a VP and you'll also get people from a different level in that same call as well so that you can really get that social interaction that you would miss out if you weren't in a physical location. Now on the other side of that, there are still physical meetups. We do still think that it's at least occasionally you come together. For engineering, we typically fly people in for a meetup once or twice a year, depending on what team that you're in. So a lot of people on the engineering team will be sort of part of their small team. So for me, it's marketing engineering. There's also a data science team when it works on our Q&A engine. And those people might come together once a year just for that team to talk to each other. But there's also a really large annual meetup that we do for everyone that touches the product. So all of marketing, all of design, all of engineering. And then we get everybody into the same room in one city once a year so that you can actually end up meeting all those people and actually put faces, real faces to those people that you're actually talking to on video chat. Now the last thing that I wanna mention here is around the non-engineering teams. Now when I say that everyone is remote, I really do mean is across the entire company. You know, it's important for teams that work with engineering to be remote first too. Communication and having the same lines of communication really enables collaboration and if you don't get everybody onto the same page, even those that are outside of the engineering culture, it's gonna be really hard to collaborate across teams. So let me give you a quick example of this. So I think about a year and a half ago, I was talking to our VP of marketing and one of the things that was happening was that they weren't really on the same lines of communication that engineering was. And what was happening was because the engineering team ended up doing, really focusing in three different areas when it came to how to communicate with each other. It was internal chat, it was Google Docs and it was also Google Hangouts. Now the marketing team instead, because they were mostly in physical locations, they were sitting next to each other. So instead of being on chat, they spoke to each other across the cubicles. When they were trying to actually have conversations when they were async, they were doing it over email. And when they had to have conversations with vendors, for example, partners, they were having phone calls or being on conference calls. And what you notice about those things is that there's very little overlap. And as a result of that, because not everybody was on the same page, there was very, very little collaboration on this 2S. And it really wasn't until we sort of started mending those two things together. The different modes of communication that the marketing team was doing and the engineering team was doing and really got them talking to each other that they started collaborating more. So, second part of this, empowerment. And this is the second part when it comes to culture here is really understanding how do you get people to work independently, largely of other people. So the first thing that I wanna mention is around gridlock. Being highly dependent on others to get things done really means that things are slower. So going back to that example of, imagine if you had to wait to push your production or if you had to wait for a code review for someone from halfway across the world. This is worse if you're in different places and times. This is not just the case when it comes to remote, it's just worse when it comes to remote. So one of the things that we wanna think about a lot at Stack Overflow to make sure that this doesn't happen is that we think about end-to-end engineering. What you do is that you allow engineering folks to be able to work end-to-end. That means taking something and having control from ideation all the way to production. When it comes to the infrastructure, some of you might have been at the talk yesterday around DevOps and how that really enables high-performing IT organizations. Really believe in that when it comes to our infrastructure too. So how do you actually allow for end-to-end engineering for remote workers is that you really make sure that you get fast deployments. You get feature-flagging, making sure that people aren't riding over each other's work. And third, that you do automated testing too. So all the things that you're thinking about, making sure that there's version control, making sure that there's no collisions around that, making sure that there's quality assurance around those things, we try to make sure that we automate as much of that as we can so that you're not necessarily dependent on other people that might be in a different time zone to make sure you can get things done. Now really when it comes down to it, all these different things around empowerment really comes down to trust too. Giving this freedom means that you trust your engineering talent is smart. You wouldn't want to be able to give all that freedom to someone that you didn't necessarily trust. So again, we go back to this idea of instead of trying to manage for that, you really think about hiring for that. And that's the second part of the smart and gets things done that I was mentioning before. You also want to make sure that the engineering talent that you're getting coming into the door, if you're going to be empowering them that much, is really, really good at engineering too. So the takeaway here when it comes to culture, remote culture means inclusive empowerment. Two things. Inclusive, making sure that everybody feels like they're on the same playing field when one person is remote, everybody is remote. And the second is around empowerment, really making sure that people feel that they have full control over their own work and they aren't too highly dependent on other people to get their work done. So the third part of how we get this done, communication. And this is really thinking about breaking out conversations out of who, when, and where those conversations occur. There's really two parts to the strategy when it comes to communication. And the first is around what we call asynchronous tools.  You can sort of send a text and then you can wait and then you can respond to it later. You don't have to be at the same time and place in order to do that. Synchronous is a phone call. You have to be there and very present in order to do that. And we focus on tools that are asynchronous. It's really difficult to get a lot of really busy people on the same time and in the same place to communicate. So instead of trying to force that happening in a remote culture, we just sort of stop trying to do that. And we focus on tools that will give us a written record. The second is this idea of public by default. So transparency, that's really what this comes down to. It's transparency and it's a really key part of our ability to be remote too. That means that we really think that information has been available to everyone by default. We really think that access really gives you, again, much more autonomy and really empowers engineers to get the work done without the dependence of other people. So asynchronous tools, and this is really addressing the when and the where. We emphasize written record whenever possible. It's really, really, really hard to try to get 12 engineers in five different time zones in the same place all the time. It's just not something that's really possible all the time. So instead of trying to force that to happen or just sort of give up on remote entirely, what we do is that we focus on communication tools that will give us a written record of something. So I'll give a few examples of what that looks like. The first really here is chat. So our primary mode of communication is internal chat. It's sort of like our main square when it comes to working with each other. And the really nice thing about having chat is that what that does is that it gives you a fully written record about all the conversations that are happening by default. So for me, I'm working here in Singapore. I'm actually still working full time while I'm out here. And we're on a completely 12 hour difference when it comes to New York City where a lot of the activity and the people that I work with is sort of happening. What ends up happening is that I can sort of continue doing my work throughout the day and go to sleep. They can see all the things that I've been working on. And when they finish their day, I can go back into the different chat rooms that I need to look at and see what conversations were being had then too, so that I'm never sort of left in the dark about what's going on. Now the next thing here when it comes to tools is around video chat. There are some times when you actually do need to talk face to face and talk things out, right? And Google Hangouts is our primary platform for this. And it works really well for ad hoc things. So they say that you're actually typing and actually having a live conversation with somebody on chat, but you don't want to go through typing all that stuff. You can just go hangout, tag the person, and it'll create a hangout internally in our chat system, and you can just jump on that hangout on an ad hoc basis. It's really, really nice. Zoom is another tool that we use for much larger groups. This is for things like town halls, where we try to get everybody in the company to listen to one of the executive team talk about something that's happening in the company. The last thing that I wanted to mention here is really docs and Trello. And this is quite literally written stuff, right? And this is where a lot of the project management that we have ends up happening. We rely heavily on Google Docs for things like specifications, and Trello for keeping track of tasks. Typical Kanban style that you'd sort of see in other agile teams. The next portion of this is something that we call public by default. And this is really about who actually owns the communication. As a company, we really value transparency and almost all information is available to everybody else in the company. And in many times, it's actually public too. It's not just within the company, it's outside of that. You know, there's some sensitive information like financial numbers or things like that, things that would give away a competitive advantage, but usually everything else, public by default. It really enables autonomy to give people access to the information that they need. So I'll give a few examples here. The first is around our weekly stand-ups. So this is one of the few exceptions that we have where we sort of require everyone to be synchronous and meeting at the same time. And it's our regular weekly stand-ups. We do this on a weekly instead of a daily basis that you might see in other places. And what we do is that we make sure that when we do our stand-ups where everybody talks about what they did a week before, what they're gonna be doing this week, and what blockers that they have, and to resolve them, that there is a public record of it somewhere so that any person can go to another team and find out what was being talked about and what they're working on. What's really nice about that is that you can get access to find out, well, if I'm working in Singapore and you know what the marketing team is doing, I can go find out that information. Now, granted, that's a lot of information if you're talking about a lot of different teams. So the other nice thing that we do is that we actually bubble up those weekly stand-up reports up into what we call a CEO report. And actually, all of this is managed inside of a trailer board so you can see all the different statuses that are happening on a weekly basis in one place. But you also get a digest of all the highlights from each of those reports in an email called the CEO report. And that happens on a weekly basis so you get a good snapshot of what's happening at the company at any one point in time. Now the thing is that this, again, comes back to empowerment. I keep talking about autonomy, empowerment, really thinking about these things. It's really another portion of this which is talking about, well, how do you make sure that people get the stuff that they need to get their work done without necessarily needing other people around them? It really, really allows people to continue working on what they need to do without having others to depend on them and having the information that they need to keep working and being productive. So last thing, when it comes to how we do this, public artifacts really allow for remote communication. Public, because we really believe in public by default. If you need information, you should have it and it should be available to you when you need it, usually in a written record of some sort. The last one is artifacts. Again, having a written record, making sure that it's acing, breaking out of when and where that communication took place. And by having both of those things put together, you really sort of solve this problem of how do you communicate across teams when they're really distributed? So this is the third part and this is the more fun part of this talk is what I call extreme remote. So this is really about pushing remote to the limit here. Now when most people think about remote work, most of them think about working from home, right?  But what if you really want to work remote but still keep your pants on because you wanted to travel? That's sort of what I was thinking about. So hello world, starting in August of last year, almost exactly a year ago, I ended up traveling while working full-time for three months. I really wanted to see not just what it would be like to work remotely outside of a physical location and stay in one place, but what would it be like if I was actually nomadic? What if I started traveling actively while I was working instead? So the idea here was that if we already have a great culture of remote work, why should I just stay in a single place? Because the idea here is that, well, if I was a European Dev, for example, and I worked out of London and I just stayed in the same place, I didn't necessarily want to live there. I just don't want to be able to travel. The really big difference here would just be that instead of every time everyone get into a Google Hangout and I had the same background, I have a different one because I'm traveling somewhere else instead. So the same principles here apply with a few special exceptions. So this is where I went in three months while I was working full-time as an engineer at Stack Overflow. I ended up going to 22 different cities in seven countries over four continents in three months. And very rarely did I actually end up staying in one place for more than a week. You can see I started in New York where I'm typically based my way through Europe, Germany, Spain, France, Italy, took a one-way flight from Rome all the way to Hong Kong, went from Taipei all the way back to San Diego, sorry, to Los Angeles and then finished up in San Diego. So just to give you a really quick understanding of sort of how this works before we move into Q&A, I just want to give you a sense of what my schedule might have been like in a single day. Let me just skip this slide really quick. So this is an actual day that I spent in Florence and this is what it would have been like when I was actually working full-time. 6.30 a.m., that's when I woke up and I really wanted to do this hike that was about two hours away by taking a train and at this point, zero hours worked. 7 a.m., I took a train to Chigaterre, that's where these hikes were actually happening and I ended up just doing a day trip before I actually had to continue my full day of work and I actually also ended up working on the train. So what I did and what I started out when I was nomadic was I ended up first catching up on emails and docs, making sure going over through the chat record the different things that people were emailing me and with all that time, it was really easy to catch up and actually do some work and with some quiet time. So at 9 a.m., I arrived at the trailhead. I already had two hours of work in because I actually did all my docs and also did my status reports and this is sort of what the trailhead looked like. So when hiking for two hours in the morning, still had two hours of work done, is what those hikes looked like. At 12.30, that's when I grabbed lunch and I still have two and a half hours. So the really nice thing about the time zone that I was in was that four to eight p.m. in Europe works to be about 10 a.m. to two p.m. in New York and that's actually a good sweet spot almost anywhere in the world. So I had about two hours left before I actually had to go back. Wrote some code locally, I was just at a cafe so that internet access could actually do some code while I was having lunch and yes, that did mean that I brought my laptop on hike. I took a train to the next town, took only like 15 minutes, still had three hours of work done and I could go to the beach because it was only 1.30 in the afternoon. That's what that looked like. 3 p.m. I took a train black to Florence and I got another two hours of work done. Again, sort of picking up the code that I did from before and moving on from there. So at the end of the train ride, I actually had five hours of work total. 5 p.m. of riding Florence, all my individual work done for the day and I could really dedicate my time to meeting starting at 6 p.m. when it was actually time to be in New York City when they were waking up. So two hour block to do meetings with New York. 8.30 p.m. Dinner, had seven hours of work done by that time and really is writing up my notes for the rest of the day and then 9.30 p.m., set the notes to the team and the day is finished and you can get, I can still get a drink if I really want to. It's still eight hour full day of work. Things I learned, it can work. The experiment was successful, right? I've been nomadic now three times, I'm actually doing it right now so this is not the last destination I have before I go back to New York City. I also realized I'm most productive at night when nobody can talk to me and I actually really get a private office and I also found out that it would probably help if I could just stay in one place longer than I needed to. It was really hard with interruptions if you travel a lot to do that and the one really funny last thing here before I finish is that it was really funny because I had to convince people that I wasn't on vacation, right? Because I was going to all these places but I was still working and I was like posting stuff to Instagram but people were like, oh I thought you were on vacation for three months and I'm like no, I'm still working full time. All right, that's it. I think we have a few minutes left for Q and A here but if you want to get these slides, I'm going to tweet these. My username is right there, John HM Chan. If you have any questions or want to ask me more about how remote works or what my nomadic trip was like, please feel free to ask. I'll be sticking around for the rest of the conference for the day. All right, thanks. Questions? Yes, right there. I'm quite curious on how you were able, I'm sorry, I'm quite curious on how you were able to somehow work out like a developer trying to push something or a code into production with the deployment team being away or the time zone is being different. So how did you empower them? So one of the really nice things about having remote work culture too is that because we're all over the world, we kind of get 24 hour coverage too. Because you're sort of in New York City, you also have people in California, you also have people in Asia and Europe. You kind of get somebody on call pretty much the entire time so you won't be completely alone when you want to do things like deployments necessarily. Now, it's not necessarily a good idea to be pushing it when there's nobody there and you have a risk of breaking all of Stack Overflow if you actually end up doing something like that. But the other nice thing is that we have a lot of automation and our DevOps team and the Site Reliability team is really, really great at making sure that you can end up doing deployments in a way that's pretty stable and pretty safe. Yes. I'd like to know how stable are your teams and how long are your projects usually? When you say stable, what do you mean by that? I mean, you stay with the same mates for a long time when you develop or going from project to project or do you switch very often? So the teams are really fluid. So there's two parts, one is about the stability and two how long the products are. The first is when it comes to stability, you end up working on a project to project basis because the teams are pretty fluid. I mean, I'm part of what's called the marketing engineering team and that means that I have to work a lot with a lot of other teams. So some teams end up working with a lot of other ones on a pretty regular basis and pretty frequently. But some teams, like the Q&A team for example, they stay pretty close and put their heads down, really focus on the Q&A product. So it really depends on what you're talking about. And when it comes to projects, that also ends up happening. That also depends too. Like I mentioned before that we had the weekly stand up that sort of gives you an idea of what the pace of things are. But the other thing here too is that a lot of engineers get a lot of autonomy like I've mentioned before to really push things through. So things like bugs, you'll see them sort of get from local to production, from discovery all the way out to a fix in a matter of minutes if you really need to. But for longer projects, things can take a few weeks to maybe a few months for really, really big projects. Other questions? Were there any legal issues when you were trying to implement remote when you were trying to do extreme remote, did you apply for work visas to work in Italy? That's a good question. So for when it came to legal issues, right? I picked a lot of the places that I ended up picking to because I wouldn't run into those issues being a United States citizen. So if you were in a different sort of situation you might have a few more restrictions there when it comes to working. But the thing is that it's no different from sort of traveling perpetually as long as you're sort of not going there to work for a company that is in that country. I was still technically working for Stack Overflow based in New York City as an American citizen. I just happened to be traveling and working at the same time. Any questions on the far sides here? I think it's on your hands. Just one question. Where's this coming from? Oh, here. Oh, sorry. So you were saying at the beginning that if remote is done properly it can be even more effective? Yeah. From what you described, the communication, you make a lot of effort to make the communication as transparent as possible. But still, if you're looking at the chat or looking at the record of the video it is not as effective as the normal meeting. So where does it coming from? Why do you think it can be even more effective than the regular office environment? So there's a few things here. The first is that you really get uninterrupted time to work. We really think, especially when it comes to engineering, when you're thinking about programming, how many of you, those of you that are programmers, how many of you have gone into a debugging hole? You go into one problem and then it turns into another problem and it gets deeper and deeper and deeper and deeper and then all of a sudden someone comes up to you and is like, hey, did you get that email I sent you? And you just lose everything. In a remote work environment, you don't get that because you have full control over when information gets to you and how that information gets to you too. Now there's a few trade-offs there. Like you Mahali mentioned, one of the things you might be thinking about when it comes to meetings is that you don't get to talk to somebody about ideas, right? But there's no reason that you couldn't do that asynchronously too, right? That's what chat is for and what email is for and what docs are for, right? You can write up all your ideas and then tag people and comments and be like, hey, what do you think of this line? What do you think of this? What do you think of this idea? Go to sleep, you wake up the next day and you get all the comments that you need from all the people that you need to. So yes, there might be a longer feedback loop there, but I don't think that it really necessarily brings down the collaboration aspect of that too, which is I think a big part of what you're thinking about when it comes to productivity outside of remote. Okay, thank you. Yes? Hello? Yeah, so have you worked in a non-remote culture before? And if yes, what's the difference in team dynamics that you see when it comes to non-remote versus remote? So that's a good question. Actually, something that I should mention is that I am technically not remote. I actually work out of our New York office and I'm based there. So most of the time I am actually in the New York office in a physical location. The really big difference is there are sort of the things I sort of just mentioned, right? I don't get live interaction when it comes to people that I need to talk to, especially when I'm in a place like Asia, for example, where everybody's on a 12 hour time difference from where it is in the United States. That being said, there's still a good sweet spot of when there's actually pretty good synchronous communication across the world. And I didn't really get to mention this, but there's sort of 10 a.m. or 2 p.m. in New York City, which is where a lot of the activity happens. That works out really well in Europe and in Asia because in Europe that's four to 8 p.m., so it's still reasonable for you to be working. And that's 10 p.m. to 2 a.m. And if you're a night owl like me, that's totally fine because that's when I'm most productive anyways. And what that ends up happening is that half of your work day is spent really doing individual work and half of your day is dedicated to meeting time whereas in a physical location, that's just interweaved across the entire day. I think that's probably the biggest difference in my mind. Other than that, we do a lot to make sure that it's not too different for each person. Then we have time for a few more. Yep. One more. All right, yes. So how do you build the company culture in the first place? So you're talking purely about remote working culture, but there is also a thing about the workplace culture and how do this aspect and building that firm culture go hand in hand? So there's a good question. When it comes to, well, besides remote culture, well, how do you build the other aspects of that culture too? The really nice thing and something that, I've been sort of talking about all these different things in the lens of remote, but the things that I'm talking about so far, really thinking about empowerment, really thinking about giving engineers end-to-end flexibility over the things that they are working on, giving people the flexibility to do the things that they want. Remote is just an expression of those values. Those things still are really, really important to people even in a physical location, right? So the things that we talk about, the onboarding, how we hire all those different pieces around the different values that we have are still part of the culture, but not necessarily just for remote. They also are expressed in how we think about management, how we think about people how, and when they perform at Stack Overflow across the entire board. So you're recruiting in the other units as well with the same case, right, in marketing in sales?  You know, everything else is a proxy for those two things and that's regardless of whether you're in engineering or something else. And the different philosophies that we have around empowerment, making sure that management is sort of a support infrastructure for people, giving people autonomy to do the work that they need is something that's across the board. Okay, all right, I think that's all the time that we have for questions, right? But if you ever have more questions, please feel free to come up to me. If you have more, go ahead, tweet at me too. I'm gonna tweet the slides as well and I'll be sticking around for the conference. Thank you everyone for your time. Thank you.


Hi friends, welcome back to my channel and welcome back to another comfort food for the entire family Yes, I'm filming my intro natural in my car because I forgot to film it And I want to make sure that I can get this video uploaded quickly for you guys So welcome to another comfort food for the entire family. This dinner was so incredibly good So good. It's a hamburger helper knockoff But it is healthy and it is delicious and it tastes in my opinion a million times better than hamburger Helper, so if you want to see tonight's comfort food for the entire family Definitely family friendly. All you have to do is stay tuned For tonight's comfort food recipe we are going to be making a recipe called hamburger, buddy So basically it is similar to a goulash. So let me show you what is going to be in tonight's Recipe, but first there's water. I just don't have that shown here So add water to the list. You're also going to need some flour minced garlic Worcestershire sauce Salt and pepper. You'll need some pasta. I'm going to be using the fiber gourmet Light elbows as you know, I love this pasta. You can have two ounces for only three smart points Versus traditional pasta that is five to six smart points for two ounces So I love it It's the only pasta that I use if you're interested in purchasing it down in the description box is a link to netrician Click the link and it'll pop you right over to this product amongst other amazing products that are WW friendly on their website. So we'll be doing fiber gourmet pasta I have some 96 for extra lean ground beef julienne carrots and onion fat-free sour cream beef broth We're going to need some time and lastly some sliced mushrooms So let's get started on tonight's dinner So the first thing you want to do is chop up your mushrooms and onions into small pieces If you don't use julienne carrots, you're going to want to cut those your carrots into small pieces as well The recipe suggests using a food processor, but I just chopped mine into small pieces So I have carrots on the bottom mushrooms and then onions and then next you're going to want to get Your meat going so you're going to want a rather large pot because this entire recipe is cooked in one pot That makes it even better So we're going to get our hamburger browning and then we'll be ready to add in our veggies and some spices Once your hamburger is completely browned We are going to add in our veggies So we've got our carrots our mushrooms and our onions and then we're going to add just a huge Keeping scoop of minced garlic and then we are going to be adding in our spices So first we're going to go ahead and add in some thyme Which I love the Trader Joe's and then we're going to do some pepper and Some salt and we're just going to give this a nice big stir And we're going to let those veggies start to soften cook down quite a bit before we continue on while your meat Is cooking you're going to take two tablespoons of flour One quarter cup of the beef broth the rest we're going to add directly to our veggies Grab a fork and we just want to combine this This is going to be our thickening agent that we're going to put in at the very end But you can go ahead and prepare in a head of thyme and then just set it aside Once your veggies get nice and cooked up. We're going to be adding in two cups of water We're also going to add in the rest of our can of beef broth After I removed that quarter cup for the flour mixture and then we're also going to add in some Worcestershire sauce I'm just going to kind of wing it We're going to let this come to a boil and then we're going to go ahead and add in our pasta So this is so nice that everything just cooks down in one pan So as soon as this comes to a boil we will add in our pasta Once it comes to a boil We're going to go ahead and add in our fiber gourmet pasta And then we're going to give it in a quick stir and then we're going to pop the lid on Actually first we're going to reduce our heat then we're going to pop the lid on and we're going to let this cook Eight to ten minutes until our pasta is cooked through. This is looking so good Once your pasta is cooked through we are going to go ahead and add in that flour and beef broth Mixture that we made and we're going to let this cook down and help thicken that little bit of liquid That's left and then the last step is to add in our sour cream And the last step is we're going to add in one half of a cup of sour cream now the recipe called for light sour cream I ended up using fat free that was all that I had on hand So my points are count are accumulated with fat free So I'm going to give you the smart points Just make sure if you end up using a light sour cream or whatever Variations you make on the recipe that you recalculate the points. So there is our completed dinner you guys this smells amazing It looks delicious. You can see here that I've transferred it to a bowl And I put it on to my food scale. Sorry got a little glare from my skylight So it is a total of two thousand and sixty grams So the best way to measure out servings from a large recipe is to take the number of grams and divide that by the number of servings So this recipe you can either divide into four servings or six servings. We're going to go ahead and divide this into Six to start I may end up doing it into four. So I'm basically going to take the twenty sixty well 2060 and divide it by four and that's the number of grams that I'm going to remove out of my bowl And that is a serving. So I've removed one sixth of the hamburger buddy So this is the one sixth amount and this is a full-size bowl So in my opinion, that's plenty So I'm going to finish getting this ready to go My veggies are in the microwave and I'll be back to show you the completed dinner and give you the smart points So here is tonight's dinner you guys this is comfort food at its finest pasta with ground beef And it's creamy with that sour cream. I tasted it and it is so good Definite must make a recipe. So again, this is one sixth of the recipe in this bowl And I'm just pairing that with some of the birds. I mixed vegetables So one sixth of this recipe is only four smart points. That's it for this entire Bowl now you do have the option to convert it into Four servings and I will put the points here on the screen if you decide to divide this out into one fourth Which is a lot because I've done mine in my husband's bowl and there's still that much left So imagine taking all of that and dividing it by four. That would be a lot of food But this is tonight's comfort food for the family definitely definitely a crowd pleaser Thank you for joining me on another comfort food for the entire family I hope you enjoyed seeing the hamburger buddy recipe. It is so incredibly good you guys You will not be sorry making this recipe adult kids Perfect perfect comfort food for the entire family. So if you're new to my channel, I'd like to extend a huge warm Welcome, make sure that you subscribe give this video a thumbs up comment down below Let me know what you thought of the hamburger buddy recipe and I'll see you guys all in the next video Have a fantastic day. Bye You


I, per tant, moltes gràcies per introduir-m'hi. Ok, ja hi anirem a parlar de Mediasub. En sort, Mediasub és una multiparty videoconferència en sistemes de noves, que és designat per a treballar amb web Cartesian points, potser brossers, potser mòbils i aplicacions, i és designat d'una manera que no és un servei comú, com que no ho sabrem, però, a més, no és un llibre, una cosa que explicaré després, en més detall. A partir d'aquí aniré a parlar de diferents multiparties multiconferències. Hi ha uns d'ells, i ho explicaré, crec que hi ha tres. El primer és de Fullmes, i això és molt fàcil, molt interessant en multiparties multiconferències, perquè, com que pots veure, no hi ha un servei de medi. Of course, there is a signaling servers on web, because there must be a way to make all the participants agree on having a room, but that's something about signaling. When it comes to the media plane, I mean, processing, receiving, sending, the media packets, in this topology there is no a media server, so it's funny for that because you don't need a media server, but it doesn't scale very well. As you can see in the picture, its participant must send all his streams, audio and video to all the other participants, which means a high uplink bandwidth requirement, which is not good for clients. Then we have a more, a better solution, which is a bit legacy right now, but it works very well. It's the MCU. In this case there is a central server, a media server, which does a lot of work, in the sense that it receives all the media streams from the participants, let it be audio, microphone, audio, and video from the webcam. The media server, the MCU, mixes all of them into a single new stream and send it back to all the other participants, so each participant sends one, sends one, and receives one. This is okay for, from the client point of view, in the sense that there is a low bandwidth requirement, and it's very easy to deal with just a single remote stream, but it doesn't let the application build interesting or cool things in the layout because you just receive a video, and if you know how to draw a video element in a web application, you know that a video is just a container and you cannot split it into multiple pieces. So, well, it's simple, it works, but we can do it better. The SFU, well, Gitchy, is also a SFU. So in this case, in this topology, there is a central server, it receives all the streams from all the participants, but instead of processing them, instead of the coding, mixing and encoding into a new single stream, it just behaves like a packet router for all the RTP packets coming to the server from the participants. So, at the end, one participant sends one and receives many. Okay, from the uplink point of view, this is okay because each participant must upload just a single stream. And for a downlink, it just, it's a browser, in this case, much receives a lot of streams, but usually the downlink is better than the uplink, so that shouldn't be a problem. And from the layout perspective, I mean from how the UI application will look, this is nice because the client will receive separate streams, so it can display them in any kind of fashion. Well, as expected, the MediaSoup is SFU, so let's see how it works. Okay, first demo. Please connect to the 4, then, Wi-Fi network. I mean just IPv6, please. It's running, the server is running in my laptop. It's running in the IPv6 network, and just in my case, I don't know, but just, for example, in my case, I had to disable the IPv4 network in order for it to connect to the internet, so... Okay, so just make sure that you have internet access to Google or whatever, and then just please join that. Well, not yet because I am gonna run the server. Well, I run out of time already, so it's enough. You can see... So you can see how each remote participant is displayed into a different container of video, so you can place them in any kind of fashion within your web application. Okay, so coming back to what MediaSoup is, one of my goals when I decide to build this media server is to make it minimalist. What does it mean? Well, it means that MediaSoup is not a common server. It's not a full application. It's not something that provides you with an init script or even a configuration file. Instead of that, MediaSoup is just AP driven by JavaScript. So it just focuses on the media plane, which means it does not provide you with a signal in protocols such as CIP, XMPP, any kind of custom protocol of a socket or whichever. It's up to the application, it's up to the developer a integrar MediaSoup into its application to decide how to signal messages from clients, browsers, to others. So, at the end MediaSoup is just a node module.  It's something that you add into your bigger node application. It's just a dependency into your application, like many others. You may want to build a real time application and you add express, so you have HTTP server and you can add socket.io, so you have chatroom, and then you can add MediaSoup into it so you can provide your application with multi-party video conferencing. So, in order to install it, it's just as any other node library, just an NPM install, MediaSoup, and that's all. Well, it's a node library or node module, so it must provide us with a JavaScript API. So, this is how it looks. Basically, here we are loading the MediaSoup module within our bigger node application running in the server, of course. We are creating a server. When we create a server, we instruct MediaSoup to launch some sub-processes that run, well, they are written in C++ and they are separate processes that manage the media layer, okay? So, then we are going to create a media room with some specific codecs. In this case, we use Opus for audio and BP-H for video. Then we create the room and the party can start. So, now it's time to add participants into the room. Well, for this task, MediaSoup provides the application or the developer with two different kinds of APIs. A low-level one, which is based on ORTC, ORTC is a specification that tries to accomplish with the same goal than WebRTC, but at a very low-level API. So, this is how MediaSoup internals work. This is a very low-level API that lets you create all the components of the communication by you, just by creating them separately. You can create a transport, you can create a receiver to receive audio from the browser, whatever. But it happens that browsers speak WebRTC, no ORTC. So, browsers deal with SDP blocks. They generate SDP blocks and they consume SDP blocks. So, we must deal with that. So, MediaSoup provides with a high-level API that, in fact, uses the low-level API inside. And this API is exactly the same as the WebRTC API. This is peer connection, create offers, local description, all of that. The Soup just forwards the media. This is not new. I mean, it does not provide you with a signaling protocol, nothing like that. And when it comes to forward media, this is how the MediaSoup worker, which is the sub-process handling the media, looks like. You can see that here we have a room with three browsers. All of them, for every browser joining this room, there is a peer instance within the MediaSoup room. Its peer instance manage its own transport and receiver and senders in order to receive media streams from the browsers and send audio and video to them. And, okay, this is how the MediaSoup provides WebRTC JavaScript API looks. If you are familiar with WebRTC API in browsers, you will know what this is about, because the API is exactly the same. So, the party starts when a participant wishes to join a room, so the application in server-side must create an offer for him, get an SDP offer, and send the offer to the client, to the remote client, maybe a browser or whichever. How to do that is up to the application. You can use SIP protocol over WebSockets by using JSCIP, for example. You can use XMPP, you can use whichever way, whichever mechanisms you wish to communicate with your browsers. So, suddenly you will receive an answer, an SDP answer from the client. And, eventually, new participants will join the room. So, when that happens, all the others will get an event, a negociació, a need event. So, the application, who is listening for that event, will call again, create offer, and send remote description. So, the browser receives a new description, a new SDP, telling him about all the remote streams that it must manage. So, suddenly, on other stream, events will happen in the browser. So, the browser will be able to display the new video of the new participants. Well, this is like before. In this case, there is a room with six participants. And, well, you can see that the CPU usage is not very... Well, it's okay, no? I think it's running in my computer, so I don't know how it would be in a server, but, well, it looks okay. We are speaking about multi... Okay, thank you, it's not mine, but... We are speaking about multi-streaming stuff. So, how do browsers behave when it comes to multi-streaming? Okay, it happens that, unfortunately, Chrome still implements his own specification on how to deal with multiple streams. At the same time, FireFox implements the new specification, the standard. So, this is a mix of different things that it is very difficult to manage. The good news are that MediaSoup does that, supports both of them, so you don't have to worry about this. Well, something about the roadmap of MediaSoup. The first version is really close. My frame, also José Luis Millán, there is working on implementing the Google Congestion Control Protocol into MediaSoup, so the video can be smoother than right now. Also, some stuff about the WebRTC provided API. And for the second version, funny things will be done, such as implementing Simulcast and SVC codecs, which Saúl already explained before. So, I'm not going to enter into details. The point is that, for example, I mean, Saúl has shown us the Gitch application. Well, that's a full application, the sense that it provides you with a complete tool of a server, a web interface, the client-side, server-side. It's an application for meetings or something like that. The point of MediaSoup is that it's not a full application. It is just a library, a server-side library for nodes. So you must integrate it into your own application and you must decide what to do. I mean, you may wish to build yet another multi-conference application for enterprise. You may wish to do something social for people to meet other people. I don't know. So, I have done that yet another application. Well, okay. I have five minutes. Okay, I just need two. Okay, in this case, well, I will show it. So please, just reload the browser. No, not yet. I must change. Okay. People are joining. More people, please. We need to meet ourselves. Okay. Sorry? Okay. Can you see it? Okay. Does it work? Can you... Sometimes in mobile, well. Just a demo. Okay, so for example, this is an application. Saul sent me a like. We can't see one to each other, but we cannot talk or listen one to each other yet. But... Hey. Oh, I don't like your voice. Sorry. So well. So well, that's all. So thanks a lot. If you have any question... We've got three minutes for questions. Okay. Bueno, Saul. Well, in fact... Okay. He's asking me about capability of Media Soop to record the streams in server-side, for example. Okay. In fact, I already provide, Media Soop already provides the application with an API to receive a raw RTP packets in JavaScript lamb. So you can manage them as you wish. You can save them into a database, I don't know. So that's for now, the API provided API. RTP, what do you mean by RTP? RTP. And the second question, why do you create the first offer from the server and not from the client? Yes, okay. Okay, first one, he's asking me about what Media Soop does with RTP processing. Okay, currently, that's something that José Luis Millán is working on. He's the RTP guy on this, okay. We now generate the receiving reports. We forward send the reports. We manage NAC. We have a RTP buffer. So if we receive a NAC from a receiver, we resend it. And the most important thing is a congestion protocol that is not yet implemented. So he's working on this right now. And the second question was... Okay. Okay. For me it's a very interesting question because I spent six months doing the opposite until I realized my error and changed two weeks ago. Okay. So the question is that if you create the offer in the server, you manage which pilot types and everything the others will need to use instead of letting them choose them. So you don't have to keep a mapping of pilot types and nothing like that. In fact, you create the offer, you own it and you own the session.  All right. Thanks, Iñaki. Okay. Thank you.


So I know that a lot of you guys have been working on your overhand serve, but you don't know exactly how to get it over I get a lot of questions like I'm doing the serve form right, but it's just not hitting the net So today we're going to talk about more in-depth how to overhand serve. Let's go It's your serve. It's important part of the serve. If you toss and it goes behind you backward when you're trying to hit the serve.   You might see some Olympic or open players toss right here and shoot at it You'll see some younger players toss all the way up and hit it The best toss is right in your field of vision right at the apex of your serve Right at the apex of your serve Then after you understand your toss and you get your toss down Then we will work on the bow and arrow and bow and arrow is a really standard part of volleyball Bow and arrow. So sometimes people open up like this Sometimes people open up like this or like this open all the way up Toss and that's when you're going to hit. So make sure you practice each key point. Keep one toss key to bow arrow key three hit key four footwork The sounds are blended together to achieve a new dimension and sound impossible to obtain in a monologue recording Now here's one of my favorite serving drills ever this serving drill I use a lot when I give lessons to beginners who are learning how to serve You're gonna stand as close to the net as possible And you're going to serve over and every time you get a successful serve over back up and eventually you'll be behind the serving line I hope that you guys liked this video and I'll see you guys next time Oh, yeah, I forgot to tell you I'm blogging about my volleyball journey to become the greatest volleyball player ever So make sure you read that on my blog on www.cocovalley.com. See you next time


Okay, let's try this one. It says calculate the z effective for the following atoms, and then it gives you these atoms sodium potassium silicon and chlorine. So remember z effective is the effective nuclear charge. So the actual amount of charge, positive charge that I'm feeling when I'm outside of the app. So if you recall z, if you recall from a long time ago, I think chapter 2, z is the nuclear charge of the atom itself, okay? And z effective, there's actually a formula that I would hope you would remember, that z effective equals z minus the number of electrons of the, we'll put it this way, the electrons of the noble gas before it, okay? So let's go ahead and look for the nuclear charge of all four of these atoms. So look up at the periodic table, sodium is what? 11, potassium 15, 19, 19, right, I got it right, right? Okay, silicon is 14, 14, and chlorine 17, 17, right? Okay, so what's the noble gas before sodium? Neon, and how many electrons does it have in it? 10, so we're just going to say 11 minus 10 equals, and this will be the z effective, so positive 1. So this one, what's the one before it? It's going to be argon, right? So that's 18 So plus 1, that's much better. This one, of course, is going to be the same as sodium, neon plus 4 will be z effective, and this one, of course, will also be neon, right? So it's going to be minus 10, it's going to be plus 6. Okay, so this z effective kind of helps you identify or kind of think about that periodic trend, about the size of the atoms themselves, so when you increase the z effective, as you go across the period, the atoms get smaller, okay? So if you'll notice, if we wanted to put these in order of biggest to smallest, we'll say sodium, silicon, and chlorine, right, because they're all in the same period, right? You'll see that sodium is the biggest because it's got the least effective nuclear charge and chlorine's the smallest because it's got the most effective nuclear charge. So if we wanted to rank these in order, right? Order decreasing order, we'll say. So that would be from biggest to smallest, and then we'll just look at those three that we were talking about, so we would say sodium is going to be bigger than silicon, which is going to be bigger than chlorine, like that. Are there any questions on that? So that kind of pits up both of those points, I think.


What we're going to do next is we're going to look at how you assign textures to specific faces So at the moment, we've just been assigning textures to Shapes as a whole so it assigns it to all the faces at once But you may need to just assign to specific faces sometimes as we need to do if we're going to texture the floor We're going to have to have just that one faced on we don't want to texture the walls with the same texture So in order to do that we shall be creating a new material, so I'm going to clear my graph I don't want my floor to be reflective. So I'm going to have a new Lambert I'm going to name that floor M and I'm going to in the same way that we've just done for the crate. I'm going to click on this Checker pattern button. I'm going to choose file and Then for the image name, I'm going to choose floor diffuse There it is. So it's just a kind of metallic panel looking thing I'm going to click on open there And then it's all about how we apply this Okay, so we need to put this into Face search and mode Now we could complicate things by going back into the modeling toolkit for this But there is an easy enough way to do it if we just right-click and hold on it You'll see that a context menu pops up and we can put it into face mode from here And then I'm going to choose this face. It just represents the floor And I can now find the floor material right-click and choose assign material to selection And then when I deselect you should be able to see If I can do object mode that that is now assigned to the floor I'm going to turn off the grid just so you can see a little bit better There you go. So that is how you assign a Texture to just one face or I could have selected two faces or 12 faces and assign it just so so it's About a sound to specific faces really