The Effective Remote Developer
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Copeland, David
Being on a distributed team, working from your home or coffee shop isn't easy, but it can be incredibly rewarding. Making it work requires constant attention, as well as support from your team and organization. It's more than just setting up Slack and buying a webcam. We'll learn what you can do to be your best self as a remote team member, as well as what you need from your environment, team, and company. It's not about technical stuff—it's the human stuff. We'll learn how can you be present and effective when you aren't physically there.
 Well, thanks. Thanks a lot for coming. My name is Dave Copeland or DaveTron5000 on Twitter, and I'm going to talk about how to be an effective remote developer, I hope. So I spent the last four and a half years as a remote developer. I was one of the first engineers at Stitchfix. We're a personal styling service for men's and women's clothes, and when I started, we were very small, you know, scrappy startup kind of thing, and, you know, I was just writing code as one does in that situation. But due to the way we work at Stitchfix and over time, my role has also changed. So I was a tech lead of a small team and now I'm a manager of several different teams. And so I've worked with a lot of different people than just developers. Certainly I work with a lot of developers, but I work with people who use our software. The business people who run Stitchfix, vendors that we rely on, all remotes for that entire time. And that's pretty typical of a developer at Stitchfix. We now have over 70 engineers, and most of the engineering work at Stitchfix is done remotely. Over half the engineers don't live in the Bay Area. We're headquartered in San Francisco, but most engineers don't live there. Those that do live in the Bay Area certainly come to the office, but they don't necessarily come in every day. So there's a lot of remote work happening. So what does that mean remote, though? When I was thinking about this, it occurred to me that people work remotely a lot more than you might think if you think about what that means. So I tried to describe it. Bear with me. You do not often interact face-to-face with the people you work with. It's not a great sentence. I tried very hard to make a better one, but I think this gets the point across, right? You go somewhere and do work. Maybe that somewhere is a coffee shop. Maybe that's your basement. And you work with people, and those people aren't there most of the time, right? So that's the situation that I mean by remote. And if you think about it like that, like, there's a lot of remote work happening in the world, not just with developers. So there's the lone wolf, right? This is the hard mode of remote where you are by yourself and everyone else you work with is at some other office. Tricky, but what we're going to talk about in this talk applies to the lone wolf. You also have easy mode, which is everybody is distributed. No one goes to an office. There is no office. One sort of works whenever, wherever. That's a little easier, but still the same things apply that we'll talk about. But think about multiple offices. Like, you could go to an office every day, have a commute, go to a desk with a computer and all of that entails, but the people you work with aren't in that office. You're a remote developer because you're working with people who aren't there. So that's what I mean by remote. So we also have to talk about what is effective. So obviously producing some value, right? Your company's paying you to do a thing and you need to do that thing. So that's part of it. But for you, you also want to be working on something valuable, right? You want to make sure that you're working on the right things, that those things are useful, that people want them or get some sort of benefit out of them. You also want to have some level of agency, right? You don't want your job to just be closing jerry tickets all the time. Like, you want to have some broader effect on the team, the people you work with, the company, something like that that's not just doing the task in front of you but growing as a person and you need agency and impact in order to do that. You want to feel included. You want to feel like part of the team. You don't want to be, again, the person whose job is just to close jerry tickets. You want to be part of the group moving forward on a collective goal. And you want the experience to be rewarding, right? No one wants their job to not be rewarding and to the extent that having to have a job is a necessity, you want it to be as rewarding as it can be. Now, I don't want to imply that you get these things for free just because you go to some office. But you get some of these things for free just by going to an office. Like, there is this sort of implicit level of effectiveness that you can just get for free by being with everyone that you work with. So what it means is to achieve these things when you're remote, you have to just work a little harder and you have to be more intentional in your behavior to make sure that stuff happens. And that's what we're going to talk about. There's not a week that goes by that I don't think about the remote experience that I have or the people I work with have. And it does require constant upkeep. And it is not what I would call easy. It's not impossible, obviously. But it is a part of my job to work on this and make sure that the behavior that I'm exhibiting is doing the best to make the remote experience good. Of course, it's worth it. Who works remote most of the time? Okay. All right. So you know what I'm talking about. It's totally worth it because you get this level of freedom and flexibility that you don't get by having to go to an office. I don't have to commute anywhere at all. I can make lunch in my kitchen. My kitchen is in fact stocked with the snacks that I prefer. And I don't have to stock other people's snacks. I can work outside if it's nice. I don't have to use a public bathroom. But the best part about working remote is I don't have to live in San Francisco. I love not living in San Francisco. It's my favorite thing. No offense to San Francisco, but I don't want to live there. Now, the company gets a benefit from this, too. The company, I'm sure, is very happy that I get to make lunch at home. But really, the company gets access to a wider pool of talent. So that's why they are also willing to spend the time on this sort of thing. So if Stitch Fix had decided that every engineer had to come to some office in San Francisco, it would have taken us much longer to build the team that we have, would have been harder to build the type of team that we have, and it would have actually had a significant impact on the company's growth. And because we committed early on to making the remote thing work, we're able to get people from all over the place. I'm not sure if you are aware of this, but there are developers who are really awesome and they don't live in San Francisco. There's a few of them. So we've got a lot of them on our team, and it's awesome. So this is how we do that. So it's not technical. I'm not going to talk about Slack or anything like that. You have to spend your energy building trust with people that you don't know and maintaining trust with people that you do know, and you have to be constantly doing this. So that's what we're going to talk about. Behaviors that you can take in a very small way that contribute to building trust with other people and acknowledging that trust. Anyone ever heard this phrase, the half-life of trust is six weeks? So there's a tiny link there that you shouldn't bother with. You can go to the slides later. It's a blog post by Steve McConnell. Steve McConnell is an author of software books. He wrote Code Complete. And in the blog post, he talks about his frustration working with a team located in India, which is halfway across the world from where he was. And he recounts one of his managers saying this phrase, the half-life of trust is six weeks, which sort of implies that if you take no action, if you don't do things to reinforce and replenish that trust, it's going to go away. And when you're not present with people, it goes away much more quickly because you don't see them. Like, you get a lot of trust by default by just being around people. And as a remote developer, you're not around people. And so you have to work extra hard to make sure that the trust that you've earned continues and that you're building more trust and just replenishing that constantly. So I've got four mindsets that you can use to drive your behavior that I believe will build and maintain trust with other people. And we're going to talk about those with respect to all the different things that we do as developers. They are communicate frequently and clearly, be responsive but set boundaries, assume good intentions, and help others help you. So the theme here is that you have the power to make your remote experience good and we're going to talk about things that you can do to do that. But we do have to have a brief chat about technology. So the biggest problem with being remote in terms of communication and building trust is, like I said, you're not actually there. So you don't have the ability to go over to someone's desk and talk to them. You have to go through some piece of technology to be able to just communicate with them. And so you're going to need a few set up. You're going to need some sort of chat system that people can use and that they check and that they're in. And I said the word people, not developers, right? So it's got to be something that every person that you need to interact with is going to be able to deal with. IRC is not that thing. I'm sorry. You're going to need a video conferencing system that accommodates multiple people and that they can use easily. And again, this is people, not developers. They should be able to include meetings and calendar invites. They should be able to connect them to room systems or other things like that. They should be able to get in and out of them very easily. So WebEx, anyone like WebEx? Anyone love WebEx? No. WebEx meets the standard even though it is terrible. So again, the bar is low. You just have to have it there. And if you don't have these things, the entire thing is very difficult. It's also not very interesting to talk about because you just sort of need to pay money and get them set up. And I don't want to trivialize that, but that just needs to happen. You also need a non-shitty microphone. So people's experience of you, yes, those of us who have dealt with shitty microphones, people's experience of you in real time is mostly going to be talking over a video conferencing system, which is very terrible because all of that entails. It's not the same as talking to a person, you know, face to face. And you can't control the crappy internet and terrible software that's involved. But you can control the input to that, which is your microphone. So your laptop mic is shitty. I'm sorry if you feel otherwise, but it is. Apple earbuds are perfectly fine. You don't need an amazing $4,000 ribbon microphone, you just need something that works and is near your mouth and Apple earbuds work. So technology over. Back to the harder parts, which is building and maintaining trust. So we, I outlined these kind of four mindsets. So I want to talk about the kinds of behaviors that they could drive when you're doing different things that are part of your job. So we code, right, mostly. Hopefully we're coding most of the time that's the output of our work. We communicate asynchronously, like with an email. We communicate synchronously, like on a video chat. And we socialize. So we'll talk about each of those four things as we go. Coding first, right? Coding, that's the thing you're hired to do. That is the thing that makes you a developer and not someone else. This is probably what you're spending most of your time doing, and this is your work product. So how do we communicate when we're coding? So think about what it's like to walk into a room with a bunch of developers. Like, what do you see? You see people typing on a keyboard into a black rectangle with white text on it. And maybe they're working, maybe they're not, but they sure look like they're working. And just that visual image is actually important, and people will assume, well, the developers look like they're developing because they're typing into rectangles. When you're remote, you don't have that at all. So, you know, to build trust, you need to produce things. And so a way to do that, which is also a great way to write code in general, is to turn larger projects into smaller ones. Find a way to take whatever your problem is and get parts of it in front of other people quickly, whatever your process is. This lets people, first of all, a small change is easy to understand. A large change is not. And so when people see you produce a small change, they're going to see that frequently, and they're going to be able to understand it and give you feedback on it. And that lets them understand you better. And that also shows that you are producing stuff and you're driving towards a result, and that builds trust because they can see that you're actually doing something. When you're making changes, think about what is the smallest viable change, right? Because you have to think about it, not just am I getting the code to work, but can someone understand what I've done so they can give me the feedback that I need to know if it's good so they can say, yes, this can go to production. You want to optimize the way you work so that people can understand that because you're not necessarily going to have another way to talk to them. The only communication you might have is the change request, whatever form that takes. So, it is not, if you're thinking about redoing the test because they're not R-spec enough, don't do that. If you're thinking about refactoring this ugly code you don't like, don't do that. If you're thinking about fixing some white space because it offends your sensibilities, don't do that. I've done all those things and it does not help communication at all. When you are submitting your change request, however you do that, so it's stitch-fixed, we make pull requests to GitHub, whatever your process is, you're presumably going to have to write something to explain what you've done. Write more about it than you might think you should. Because, again, you're optimizing for people to understand what you've produced and so you need to give them some clue as to what they're looking at and why they need to look at it and what you want them to look at. So, when I do this I try every time to write the word problem and hit return and I type a sentence or two about what I'm trying to accomplish. I hit return, I type solution and hit return again and I write some couple of sentences about how I approached it, what I tried to do. To give somebody a chance at understanding what I've done because that might be the only chance they get to understand what I've done. More practically speaking, learn how to screencast and diagram. So, early on at Stitch Fix I was working on software and there wasn't an easy way to share it with anyone. There wasn't really a staging server that anyone could feasibly use and I'm not there to bring my laptop over to show it to someone. So, I would just run the app on my laptop and screencast and just talk over using the app in my development environment and that is way easier to explain what you're doing than typing a bunch of stuff out. I use this thing called Jing. It's free for five minutes or less. You can share this screencast privately. If you just get really good at doing that quickly then this is a thing you can just do without friction and include. Diagram is the same way. Just buy OmniGraphil and learn the keyboard shortcuts and then you will make diagrams very quickly and easily and then that is a thing you can bring to better communicate with people. Being responsive and setting boundaries. So, the first boundary you need to set is your working hours, especially when there's time zones, right? I mean, does anyone like time zone math? Because talk to non-developers. They don't even know what it is. They're not going to do it. So, you need to help them. So, there's a lot of ways to do this and you have to take a wide approach. So, I set in my calendar what my working hours are. I include my time zone in my email signature and then when people are interacting with me I am trying to be nice about what my working hours are. So, if someone schedules a meeting with me at like six o'clock, I say, hey, that's a little bit late for me. I don't know if you know this. I'm on the East Coast. Can we do this later? Right? It's a very nice way to kind of set some boundaries and not being a jerk. Or if someone's giving me feedback or I'm chatting with someone I might have to say, hey, it's the end of my day. I got to take off. Let's pick this up in the morning. Right? So, but you do need to set those boundaries because people aren't going to know and they need to know. So, when you're asking for feedback, when you're writing your code and you're like, this is done. I'm ready. What is the next step? Someone has to like say, yeah, cool. Or whatever the process is, you're kind of watching for feedback. And so, the second you do that, your job then becomes to respond to that feedback. Why? First of all, it shows that you're engaged and that you're trying to drive completion, which builds trust because people like people that drive to completion. But it also allows you to capitalize on the context that people develop by giving you feedback. If someone like reads your poll request and gives you feedback and then you don't respond to it for a couple of days, well, they've forgotten whatever they looked at and they have to go relearn it again if they're going to engage with you. But if you do it quickly and you engage with them back and forth, then you're making everything better. And what I've learned is you need to develop a workflow that does not put you heads down away from all forms of communication for hours at a time. And this is really hard because sometimes as developers, we need to do this. But the more you are not able to be contacted, right, people can't walk over to you. So, they have no way to contact you except for the avenues that you have set up and created. And if you're not responsive to them, then they can't take advantage of your expertise. And that is going to drive you more towards the JIRA ticket closer and not closer to a full-rounded developer who has agency and impact and is growing the team and growing themselves. So, I will happily tell you my crazy workflow that I do for this. It might not work for you. But the gist of it is I have an SLA for all forms of communication. And I try to stick to that. And I have a way that while I'm working, I can check all the forms of communication to see if I need to do anything without forgetting my spot. Whatever works for you, try to find some way to do that. And the more you do build up trust, though, the more you can kind of get away with being offline for a little while. So, this could be a thing where early on you need to focus on being more responsive. And as you kind of build up trust with people, you can take more time to do this stuff. This is hard to do. It's very hard. Assume good intentions. So, code review comments. Anyone like any of their code commented on? Was that a fun experience? Okay. Yeah, it's very harsh. We as an industry aren't used to critiquing each other. We're not used to being critiqued. We're not good at it. And either ends. And so, it can be hard to accept. And also, people are bad at it. And it can often come off mean. Or you can read a tone into it that is unpleasant. It's not good. But you have to assume, the only way to deal with this is to assume that the reviewer, whoever is telling you stuff about your code, they're just trying to help. They're trying to help make your code better, make you better, make the company better, whatever it is they're trying to help or they wouldn't bother commenting. I'm not saying to tolerate bad behavior, but bad behavior is a pattern that you can observe. One time thing, you have to assume good intentions, otherwise you'll go crazy. Now, a way to deal with this problem is, leads to helping others help you. Not everyone is good at it, like I said, but some people are exceptionally good at just talking. So, if you're having an interaction in text that is not working, then jump to video. Like, this is my failure mode all the time, is I never go to video. But if you go to where someone communicates well, then you will have good communication with them. Right? It kind of, right, stands to reason. And instead of making people come to you, you should also be specific in the feedback that you want. If you put up a portal quest and say thoughts, you're not likely to encourage good feedback. So, if you actually specify, like, what are the areas of your code that you want someone to, like, look at? Like, oh, this variable name, I had a hard time coming up with it, I don't know, does this make sense? Or does this method like make any sense? Could someone sort of, like, help me understand does this look right? So, that does several things. One, it lets people, like, quickly figure out what to do and can more easily engage with you, which means that you will engage with them. And, you know, that kind of builds trust. But it also shows a little bit of vulnerability, which is huge for building trust, because it shows that you're willing to acknowledge areas of your code that aren't perfect. And so, then when people interact with you, they know that they're getting an honest and authentic experience, because you're willing to call out things that aren't perfect. Okay, code. Asynchronous communication. So, all this coding stuff is a form of asynchronous communication. It's very specific to our profession. But you're also going to interact with people not about code, writing emails, sharing documents, texting in Slack or something like that. There's all kinds of asynchronous communication. And this is the primary way you're going to communicate with most people, just by nature of being remote. Fortunately, this is a little easier to deal with. So, communicating frequently and clearly. You have to provide more context. So when you're talking to somebody, you can see their eyes start to glaze over, you can see them get confused, they can raise their hand, they can interrupt you if you're not, like, making a point. But in an email or a document, like, you're not going to get that. You might never know if someone understood an email that you sent. So you need to provide a little bit more context to increase the chance that they are going to understand that. So, explicitly state what problem you're trying to solve or what information you want or what you want them to do and why give some more back story so that there's a chance that they get what you mean. You should also become a better writer because you're going to be writing a lot. And this is how to do that. So you write something, you want someone to read. The least you can do is read it yourself first. And when you do that, you find all kinds of mistakes in your writing. You find all kinds of incorrect words and other things. So everything that I write, I read at least once and I revise at least once because there's always a way to make it better. And I just do this all the time. And as you do this more and more, you make a habit out of this, then you will do it frequently and the more important an email might be or whoever you're sending it to, you will revise more and more. And it just makes you more effective at communication when you're sort of at least taking it for a dry run. Typography matters. A wall of text is impossible to understand. Like hit return a few times, make some paragraphs at least. Every few sentences there should be a paragraph or something. But bold, italics, underline, like those exist, they have meaning, you should use those. Bullet lists, I mean it's stupid to say any of this but I remember in my youth every email was just nothing but courier text wrapped at 80 characters and if people wanted bold then that was their problem, right? That is not the way to effectively communicate. Again, the diagramming thing is really helpful especially when you're communicating to outside developers or people who are not good at processing text which is lots of people, learn how to make diagrams quickly and efficiently and that's a tool that you can bring to bear and make things more clear. Being responsive. So a lot of the things we talked about with code kind of apply here. The point is you want to engage, give feedback if you're being asked for it, ask for feedback if you want it, like engage so that you're interested in helping someone solve their problem. Because when you do this, this is how you get agency and this is how you have an impact, right? And this is why being responsive is so important. You have an opinion about things and if you don't share that opinion with anyone then that opinion is not going to affect anything. It's just an opinion that you have. But if you share your opinion with people then that is a chance for you to affect how things are and if your opinions are good and they are helpful then you will be seen as someone who is good and helpful. And that is, that means people will trust your opinion and trust you and come to you and ask you for things and give you more of an impact on what you do and that makes a much better work experience. So being responsive and helping people out is good. But don't forget affirming feedback. So all the stuff we've been talking about about feedback is like critiques, this is wrong, fix this, blah, blah, blah, it's very easy to get wrapped up in that and we do want those. That is the critique that we want because we want to be better. But it is nice when someone tells you that the thing you did is good and it's even nicer when they say it in a very detailed way. So if you say, oh, that API design looks good. I mean that's nice, that's very nice. But if you say the names you're using in the route map exactly to the domain which makes it really easy for me to understand this whole thing is like really simple. Thanks for putting this together. That is really great to hear because it shows that you've understood what they've done and that you took the time to say something nice and it's if you're a person that says nice things to people and makes them feel good, that builds trust. So I used to think affirming feedback was pointless, it is not pointless, it is very, very pointless. Assume good intentions. So a lot of asynchronous communication you have as a developer will be with non-developers. Sometimes there are people that use ask as a noun or use solution as a verb and if you're like me it drives you completely insane. But the point is that's just a communication style, it's not an indicator of ability. So I choose and this is hard but I choose to assume that everyone I interact with is killing it at their job that they're really good at their job. Because that mindset is the only way to deal with other people otherwise you get wrapped up in communication style. I mean the number of power points that I have had to have a conversation about in the last four years is kind of staggering but that's how some people communicate and that's cool because they're good at their job and that's fine. But help others help you. So again, kind of same deal, ask for the feedback that you want. The other cool thing about this is this is another avenue to give context to help people understand what you're doing. If you're telling them what you want that helps them figure out what it is you're trying to accomplish and is much more likely to garner some back and forth. So this is the hard, for me anyway this is the hardest part, is synchronous communication which basically means being on some sort of video conferencing system. Why? I mean part of it is I'm an introvert and so this saps my energy to have conversations but another part of it is that it's this weird uncanny valley version of having a conversation with a real person, right? Because you can see them and you can hear them but everything between you and them is terrible software that barely works and the whole thing is just awful. And so it's just more stressful to have to deal with this but some conversations cannot happen over text. Like you have to have synchronous conversations sometimes. So how do we deal with this? Be prepared. So I find if I'm expected to like say words to people the more confident I am in the subject matter the more likely I am to say something that makes sense. So read the material before the meeting. See who's there, what is the meaning about? Do you have an opinion about what we're going to discuss? If so formulate that opinion in your mind at some level of detail so if you have to say something it will make sense and people will get it. You should also try to speak with more nouns than pronouns. When you say stuff like he, she, it, they, this, that, thing, things not a pronoun but you know what I mean. Those words don't mean anything. Who knows what that means? The only way you can know is if someone said a noun before and you have, you can guess that that noun is the thing that that means and okay now I get what you're saying. And when you're talking to a person like face to face you can see them get confused and be like ah okay sorry this is what I meant blah blah blah. When you're on a video you can't see that. Also due to technology you will not be heard. Everything you say is not going to be heard. Someone coughs, a word is going to drop out, two people start talking, there's crosstalk, people aren't going to hear what you say. The internet drops for a microsecond and one word goes. I've been on video chats where I missed the noun because of technology and then for two minutes people were discussing and they never used a noun and I literally couldn't figure out what they were talking about and I had to interrupt and say what is the noun please. I don't know what this means. I'm sorry you've got to tell me. So when you do that that means that the things that people do here they're more likely to know what you're talking about. A better way is to pause frequently and ask for feedback right because people can't interrupt. Interrupting on video is very hard. People aren't going to necessarily do it. So take a moment. Okay. This is my proposal for how we're going to do this JSON thing. Does that make sense everybody? And then you have this pause. When we do our all hands engineering meetings at such fix like I said a lot of us are remote and our CTO is really good at doing this. She'll give us information and then she will pause and say anybody have any questions and then if nobody in the office has questions she will always say anybody on the phone have any questions. And then pause for a very uncomfortable amount of time because she knows that it takes a while for us to oh do I have a question? I do have a question. Let me ask that question. That takes a while. So she puts those pauses in there so that nobody has to interrupt and everyone has a chance to participate. So when you're speaking you should do that. Being responsive and setting boundaries. This is kind of the other end of this. For me this is the absolute hardest part. It's not multitask. So if you are in a conference room with people and you're on your phone or you're on your laptop like that's very rude and so you wouldn't do that because social norms say I got invited to a meeting I should pay attention to the meeting I shouldn't be on my phone. But when you're on a video conference you're literally on your computer and stuff is popping up and you can check email and Slack and you can do these things. You can tell yourself that you can multitask but you're not really paying attention and then either you miss things that are important or you get called out. I have definitely been asked questions in meetings where I have no idea what to say and I just had the cop to it. I'm sorry I was multitasking please repeat the question. That's super embarrassing. When you do have something to say it is very awkward to jump in but sometimes you're going to have to and because of all the delays that happen you may have to ask the group to backtrack and just be up front about it. Hey I'm sorry to jump in here real quick but can we go back for a second. I had this thing and this comment like it's hard to do this. Some people just can't. I have a hard time not as hard as others. The pausing thing that I talked about if others are doing that that helps and when you do have the floor that is your time to set an example on explicitly calling on other people especially people that you know are not going to be comfortable jumping in but you know have an opinion. That is a really good technique. Oh Chris you just did this thing what's your thoughts right or anyone on the phone else have something before we move on. That's how these meetings should be run and so you have to set that example whenever you can. No one's going to know that the AV is a problem but you. This is like when someone has something on their teeth you just have to tell them because no one's going they're not going to know so you have to be comfortable pointing it out. It sucks but that is a fact of life. And of course you have to be self aware. These behaviors that I'm describing that kind of have to exist on some level are jerky behaviors if they're done too much or too frequently or too aggressively and so you need to have a lot of self awareness when you do this. You've been asking people for feedback when you're offline to say hey I'm sorry I kept interrupting you. I'm really not trying to talk over you but maybe I was like give me your feedback on how that went so I can get better. Like yeah it's definitely hard. And that sort of follows on assuming good intentions because people are going to interrupt you and it's going to seem jerky and you have to assume that they're just trying to deal with the technology. The other thing though is that the people who are maybe not remote who are part of this who are in this mythical conference room they're not having a great time with the video chat either. Like it's not great for them to have all of this stuff going on and it is friction for them and having some empathy for them is really helpful because it's actually something that you all can bond over. I complain about the technology all the time and it's kind of can lighten the mood sometimes. Because computers are terrible. You have to rely on all of these servers and all these pieces of technology and they all barely work. I'm amazed it works at all. They don't work consistently. It's just all just terrible. And acknowledging that can make everyone sort of feel a little bit better about getting through the video conferences. Helping others help you. So I mentioned before about the AV system issues. This will definitely happen and you need to kind of channel your inner wedding coordinator and just tell people what they need to do because they're not going to know. Hey, point the laptop at Pat because Pat is the one who's speaking. Just tell people what to do. They're happy to fix it but they're not going to know because they're not experiencing the AV the same way that you are. If you can recruit an ally or have a blessed back channel that is really helpful too. So at Stitch Fix we do company all hands meetings and as I mentioned a lot of developers are remote but there's a lot of other remote people. We have lots of different offices. Our stylists are remote. People are traveling. So remote is a big part of our all hands meetings. And there's a wonderful person on our ops team who monitors the back channel and she asks questions for us and she fixes AV problems and we can handle this all by chatting and not interrupting the meeting. So if you have an ally that is super helpful. Okay, socializing. Why are we talking about socializing? You go to an office. People know things about you. Even if you're the most private person on the world and you never say anything to anyone, people will know what kind of clothes you wear, what your hair looks like, how tall you are, what time of the day you come into work, how often you go to the bathroom. These are banal silly things but people will know them about you and if you are not going to an office they will know absolutely nothing about you. I'm amazed at the height of my coworkers when I first meet them. It's not what I expect ever. So what this means sadly for the introverts is you're going to have to make small talk. You have no other way to interact with people and when you're on these video conferences, especially with the West Coast, people are going to be late and so you have a lot of time to kill. You're waiting for everyone to find the conference room and get there. So make small talk. It sucks but you can talk about the weather. It's the beginning of a conversation, a beginning of a personal connection. For me it's easy because I live in D.C. where we have weather. San Francisco, they don't have weather so it's always an evergreen topic. Another thing that we do is we do one-on-ones with people that aren't our manager or aren't our direct report or anything like that with no particular agenda. So I have a lot of one-on-ones with people where we'll talk about work sometimes but we'll also just chit chat. Sometimes it's just five minutes but it's a time set aside to interact as people as best as we can and it feels awkward to schedule these sorts of things but it's the only way to make them happen and it feels normal after a little while. Being responsive and setting boundaries. This is more about travel. Getting together with people helps replenish this trust a lot. It is really handy if you can do it. Travel is a pain so you want to make sure you understand what are the expectations hopefully before you take the job. I guess I'm saying this because you might not be told what the expectations are because it might not occur to someone that travel is difficult for you or something like that. So be clear about what the expectation is and try to do it when you can. I mean a lot of us work remotely because travel is difficult or we want the flexibility to run our lives in a certain way and travel sort of disrupts all that. It's totally true and definitely set boundaries but if you can travel it is worth it to reestablish those bonds with the people that you work with every day because you do refresh that trust by seeing people in person. Assume good intentions. Right. So people are going to make a small talk with you too because they're going to want to know who you are and they might ask things that are uncomfortable and they're not trying to be nosy. They just want to get to know who you are. If you have things about your personal life that you don't want to talk about that's totally normal and totally cool but that's all the more reason to do that whole small talk thing. If you're driving the chit chat then you can drive it in the direction that is safe for everyone. And just be okay missing social events like happy hours. My respect and admiration for my coworkers is not derived by the number of beers I have shared with them. It is by the good work that we do as a mindset I take and so therefore I don't care if I miss happy hours or social events. I enjoy them when I can make them and it is nice to have a beer with my coworkers but many of them I've never socialized with at all and they're still great people that I love to work with. You just have to sort of be cool with it. But it doesn't mean you can't socialize at all or you have to miss everything. What it kind of means is that it might not be clear what those things are and if you have ideas bring them up. You'd be amazed at how successful you can be by bringing your boss an idea that requires your boss to do absolutely nothing but say yes. You do that you're good. But it does mean you've got to take the initiative there. If you can find a way to have in-person meetups, be creative about it. There's a couple of developers live on either side of our Dallas warehouse and every once in a while they will go to the Dallas warehouse and work together. They don't work on the same project but they get to see each other in person and have a little social interaction. Be creative and bring them up and suggest them and often your boss will be happy that you're helping to figure this problem out because they're not going to know how to make the experience good for you. All of that are tiny little things that all build little bits of trust between you and others. When you're trusted and you work with people that you trust, you are going to be way more effective at your job, way happier. You're going to have much more agency. You're going to be producing much more value. You're going to feel included and the whole experience is going to be much more rewarding. That's it. These are the four mindsets again. Be frequently and clearly. Be responsive but set boundaries. Assume good intentions and help others help you. I have just kind of described how things are in my company and so you should come work for us or just talk to us and we'll tell you how this is and we can give you all kinds of details on how this stuff works for us. That other link is for these slides that you can check out if you like. Thank you. The question is when there's social events and there's business talk, you're missing out on that and that's a potential thing. That is absolutely a problem and that's sort of a company culture thing. It's hard to fight information happening that you aren't even aware it's happening. That is tough. Getting to know the company culture before you make decisions helps and asking about that directly sometimes is the way to do that. That is potentially a problem for sure. What's the good frequency for visiting up with people? When I started, I did every two months because I was new and I knew I had to put a lot of effort into making it work and that was helpful. Right now, the team gets together every three months. For me personally, I do that but then I end up going for random other things in between. Everyone comes every three months and that seems to work pretty well. Thanks a lot, everybody.
 Well, thanks. Thanks a lot for coming. My name is Dave Copeland or DaveTron5000 on Twitter,  and I'm going to talk about how to be an effective remote developer, I hope. So I spent the last  four and a half years as a remote developer. I was one of the first engineers at Stitchfix.  We're a personal styling service for men's and women's clothes, and when I started, we  were very small, you know, scrappy startup kind of thing, and, you know, I was just writing  code as one does in that situation. But due to the way we work at Stitchfix and over time,  my role has also changed. So I was a tech lead of a small team and now I'm a manager of several  different teams. And so I've worked with a lot of different people than just developers.  Certainly I work with a lot of developers, but I work with people who use our software.  The business people who run Stitchfix, vendors that we rely on, all remotes for that entire  time. And that's pretty typical of a developer at Stitchfix. We now have over 70 engineers,  and most of the engineering work at Stitchfix is done remotely. Over half the engineers  don't live in the Bay Area. We're headquartered in San Francisco, but most engineers don't  live there. Those that do live in the Bay Area certainly come to the office, but they don't  necessarily come in every day. So there's a lot of remote work happening. So what does  that mean remote, though? When I was thinking about this, it occurred to me that people  work remotely a lot more than you might think if you think about what that means. So I tried  to describe it. Bear with me. You do not often interact face-to-face with the people you  work with. It's not a great sentence. I tried very hard to make a better one, but I think  this gets the point across, right? You go somewhere and do work. Maybe that somewhere  is a coffee shop. Maybe that's your basement. And you work with people, and those people  aren't there most of the time, right? So that's the situation that I mean by remote. And if  you think about it like that, like, there's a lot of remote work happening in the world,  not just with developers. So there's the lone wolf, right? This is the hard mode of remote  where you are by yourself and everyone else you work with is at some other office. Tricky,  but what we're going to talk about in this talk applies to the lone wolf. You also have  easy mode, which is everybody is distributed. No one goes to an office. There is no office.  One sort of works whenever, wherever. That's a little easier, but still the same things  apply that we'll talk about. But think about multiple offices. Like, you could go to an  office every day, have a commute, go to a desk with a computer and all of that entails,  but the people you work with aren't in that office. You're a remote developer because  you're working with people who aren't there. So that's what I mean by remote. So we also  have to talk about what is effective. So obviously producing some value, right? Your company's  paying you to do a thing and you need to do that thing. So that's part of it. But for  you, you also want to be working on something valuable, right? You want to make sure that  you're working on the right things, that those things are useful, that people want them or  get some sort of benefit out of them. You also want to have some level of agency, right?  You don't want your job to just be closing jerry tickets all the time. Like, you want  to have some broader effect on the team, the people you work with, the company, something  like that that's not just doing the task in front of you but growing as a person and you  need agency and impact in order to do that. You want to feel included. You want to feel  like part of the team. You don't want to be, again, the person whose job is just to close  jerry tickets. You want to be part of the group moving forward on a collective goal.  And you want the experience to be rewarding, right? No one wants their job to not be rewarding  and to the extent that having to have a job is a necessity, you want it to be as rewarding  as it can be. Now, I don't want to imply that you get these things for free just because  you go to some office. But you get some of these things for free just by going to an  office. Like, there is this sort of implicit level of effectiveness that you can just get  for free by being with everyone that you work with. So what it means is to achieve these  things when you're remote, you have to just work a little harder and you have to be more  intentional in your behavior to make sure that stuff happens. And that's what we're  going to talk about. There's not a week that goes by that I don't think about the remote  experience that I have or the people I work with have. And it does require constant upkeep.  And it is not what I would call easy. It's not impossible, obviously. But it is a part  of my job to work on this and make sure that the behavior that I'm exhibiting is doing  the best to make the remote experience good. Of course, it's worth it. Who works remote  most of the time? Okay. All right. So you know what I'm talking about. It's totally worth  it because you get this level of freedom and flexibility that you don't get by having to  go to an office. I don't have to commute anywhere at all. I can make lunch in my kitchen. My  kitchen is in fact stocked with the snacks that I prefer. And I don't have to stock other  people's snacks. I can work outside if it's nice. I don't have to use a public bathroom.  But the best part about working remote is I don't have to live in San Francisco. I love  not living in San Francisco. It's my favorite thing. No offense to San Francisco, but I  don't want to live there. Now, the company gets a benefit from this, too. The company,  I'm sure, is very happy that I get to make lunch at home. But really, the company gets  access to a wider pool of talent. So that's why they are also willing to spend the time  on this sort of thing. So if Stitch Fix had decided that every engineer had to come to  some office in San Francisco, it would have taken us much longer to build the team that  we have, would have been harder to build the type of team that we have, and it would have  actually had a significant impact on the company's growth. And because we committed early on  to making the remote thing work, we're able to get people from all over the place. I'm  not sure if you are aware of this, but there are developers who are really awesome and  they don't live in San Francisco. There's a few of them. So we've got a lot of them  on our team, and it's awesome. So this is how we do that. So it's not technical. I'm  not going to talk about Slack or anything like that. You have to spend your energy building  trust with people that you don't know and maintaining trust with people that you do  know, and you have to be constantly doing this. So that's what we're going to talk  about. Behaviors that you can take in a very small way that contribute to building trust  with other people and acknowledging that trust. Anyone ever heard this phrase, the  half-life of trust is six weeks? So there's a tiny link there that you shouldn't bother  with. You can go to the slides later. It's a blog post by Steve McConnell. Steve McConnell  is an author of software books. He wrote Code Complete. And in the blog post, he talks about  his frustration working with a team located in India, which is halfway across the world  from where he was. And he recounts one of his managers saying this phrase, the half-life  of trust is six weeks, which sort of implies that if you take no action, if you don't do  things to reinforce and replenish that trust, it's going to go away. And when you're not  present with people, it goes away much more quickly because you don't see them. Like,  you get a lot of trust by default by just being around people. And as a remote developer,  you're not around people. And so you have to work extra hard to make sure that the trust  that you've earned continues and that you're building more trust and just replenishing  that constantly. So I've got four mindsets that you can use to drive your behavior that  I believe will build and maintain trust with other people. And we're going to talk about  those with respect to all the different things that we do as developers. They are communicate  frequently and clearly, be responsive but set boundaries, assume good intentions, and  help others help you. So the theme here is that you have the power to make your remote  experience good and we're going to talk about things that you can do to do that. But we  do have to have a brief chat about technology. So the biggest problem with being remote in  terms of communication and building trust is, like I said, you're not actually there.  So you don't have the ability to go over to someone's desk and talk to them. You have  to go through some piece of technology to be able to just communicate with them. And  so you're going to need a few set up. You're going to need some sort of chat system that  people can use and that they check and that they're in. And I said the word people, not  developers, right? So it's got to be something that every person that you need to interact  with is going to be able to deal with. IRC is not that thing. I'm sorry. You're going  to need a video conferencing system that accommodates multiple people and that they can use easily.  And again, this is people, not developers. They should be able to include meetings and  calendar invites. They should be able to connect them to room systems or other things like that.  They should be able to get in and out of them very easily. So WebEx, anyone like WebEx?  Anyone love WebEx? No. WebEx meets the standard even though it is terrible. So again, the  bar is low. You just have to have it there. And if you don't have these things, the entire  thing is very difficult. It's also not very interesting to talk about because you just  sort of need to pay money and get them set up. And I don't want to trivialize that, but  that just needs to happen. You also need a non-shitty microphone. So people's experience  of you, yes, those of us who have dealt with shitty microphones, people's experience of  you in real time is mostly going to be talking over a video conferencing system, which is  very terrible because all of that entails. It's not the same as talking to a person,  you know, face to face. And you can't control the crappy internet and terrible software  that's involved. But you can control the input to that, which is your microphone. So your  laptop mic is shitty. I'm sorry if you feel otherwise, but it is. Apple earbuds are perfectly  fine. You don't need an amazing $4,000 ribbon microphone, you just need something that works  and is near your mouth and Apple earbuds work. So technology over. Back to the harder parts,  which is building and maintaining trust. So we, I outlined these kind of four mindsets.  So I want to talk about the kinds of behaviors that they could drive when you're doing different  things that are part of your job. So we code, right, mostly. Hopefully we're coding most  of the time that's the output of our work. We communicate asynchronously, like with an  email. We communicate synchronously, like on a video chat. And we socialize. So we'll  talk about each of those four things as we go. Coding first, right? Coding, that's the  thing you're hired to do. That is the thing that makes you a developer and not someone  else. This is probably what you're spending most of your time doing, and this is your  work product. So how do we communicate when we're coding? So think about what it's like  to walk into a room with a bunch of developers. Like, what do you see? You see people typing  on a keyboard into a black rectangle with white text on it. And maybe they're working, maybe  they're not, but they sure look like they're working. And just that visual image is actually  important, and people will assume, well, the developers look like they're developing because  they're typing into rectangles. When you're remote, you don't have that at all. So, you  know, to build trust, you need to produce things. And so a way to do that, which is  also a great way to write code in general, is to turn larger projects into smaller ones.  Find a way to take whatever your problem is and get parts of it in front of other people  quickly, whatever your process is. This lets people, first of all, a small change is easy  to understand. A large change is not. And so when people see you produce a small change,  they're going to see that frequently, and they're going to be able to understand it  and give you feedback on it. And that lets them understand you better. And that also  shows that you are producing stuff and you're driving towards a result, and that builds  trust because they can see that you're actually doing something. When you're making changes,  think about what is the smallest viable change, right? Because you have to think about it,  not just am I getting the code to work, but can someone understand what I've done so they  can give me the feedback that I need to know if it's good so they can say, yes, this can  go to production. You want to optimize the way you work so that people can understand  that because you're not necessarily going to have another way to talk to them. The only  communication you might have is the change request, whatever form that takes. So, it  is not, if you're thinking about redoing the test because they're not R-spec enough,  don't do that. If you're thinking about refactoring this ugly code you don't like, don't do that.  If you're thinking about fixing some white space because it offends your sensibilities,  don't do that. I've done all those things and it does not help communication at all.  When you are submitting your change request, however you do that, so it's stitch-fixed,  we make pull requests to GitHub, whatever your process is, you're presumably going to  have to write something to explain what you've done. Write more about it than you might think  you should. Because, again, you're optimizing for people to understand what you've produced  and so you need to give them some clue as to what they're looking at and why they need  to look at it and what you want them to look at. So, when I do this I try every time to  write the word problem and hit return and I type a sentence or two about what I'm trying  to accomplish. I hit return, I type solution and hit return again and I write some couple  of sentences about how I approached it, what I tried to do. To give somebody a chance at  understanding what I've done because that might be the only chance they get to understand  what I've done. More practically speaking, learn how to screencast and diagram. So, early  on at Stitch Fix I was working on software and there wasn't an easy way to share it with  anyone. There wasn't really a staging server that anyone could feasibly use and I'm not  there to bring my laptop over to show it to someone. So, I would just run the app on my  laptop and screencast and just talk over using the app in my development environment and  that is way easier to explain what you're doing than typing a bunch of stuff out. I  use this thing called Jing. It's free for five minutes or less. You can share this  screencast privately. If you just get really good at doing that quickly then this is a  thing you can just do without friction and include. Diagram is the same way. Just buy  OmniGraphil and learn the keyboard shortcuts and then you will make diagrams very quickly  and easily and then that is a thing you can bring to better communicate with people. Being  responsive and setting boundaries. So, the first boundary you need to set is your working  hours, especially when there's time zones, right? I mean, does anyone like time zone  math? Because talk to non-developers. They don't even know what it is. They're not going  to do it. So, you need to help them. So, there's a lot of ways to do this and you have to take  a wide approach. So, I set in my calendar what my working hours are. I include my time  zone in my email signature and then when people are interacting with me I am trying to be  nice about what my working hours are. So, if someone schedules a meeting with me at  like six o'clock, I say, hey, that's a little bit late for me. I don't know if you know  this. I'm on the East Coast. Can we do this later? Right? It's a very nice way to kind  of set some boundaries and not being a jerk. Or if someone's giving me feedback or I'm  chatting with someone I might have to say, hey, it's the end of my day. I got to take  off. Let's pick this up in the morning. Right? So, but you do need to set those boundaries  because people aren't going to know and they need to know. So, when you're asking for feedback,  when you're writing your code and you're like, this is done. I'm ready. What is the next  step? Someone has to like say, yeah, cool. Or whatever the process is, you're kind of  watching for feedback. And so, the second you do that, your job then becomes to respond  to that feedback. Why? First of all, it shows that you're engaged and that you're trying  to drive completion, which builds trust because people like people that drive to completion.  But it also allows you to capitalize on the context that people develop by giving you  feedback. If someone like reads your poll request and gives you feedback and then you  don't respond to it for a couple of days, well, they've forgotten whatever they looked  at and they have to go relearn it again if they're going to engage with you. But if you  do it quickly and you engage with them back and forth, then you're making everything better.  And what I've learned is you need to develop a workflow that does not put you heads down  away from all forms of communication for hours at a time. And this is really hard because  sometimes as developers, we need to do this. But the more you are not able to be contacted,  right, people can't walk over to you. So, they have no way to contact you except for  the avenues that you have set up and created. And if you're not responsive to them, then  they can't take advantage of your expertise. And that is going to drive you more towards  the JIRA ticket closer and not closer to a full-rounded developer who has agency and  impact and is growing the team and growing themselves. So, I will happily tell you my  crazy workflow that I do for this. It might not work for you. But the gist of it is I  have an SLA for all forms of communication. And I try to stick to that. And I have a way  that while I'm working, I can check all the forms of communication to see if I need to  do anything without forgetting my spot. Whatever works for you, try to find some way to do  that. And the more you do build up trust, though, the more you can kind of get away  with being offline for a little while. So, this could be a thing where early on you need  to focus on being more responsive. And as you kind of build up trust with people, you  can take more time to do this stuff. This is hard to do. It's very hard.  Assume good intentions. So, code review comments. Anyone like any of their code commented on?  Was that a fun experience? Okay. Yeah, it's very harsh. We as an industry  aren't used to critiquing each other. We're not used to being critiqued. We're not good  at it. And either ends. And so, it can be hard to accept. And also, people are bad at  it. And it can often come off mean. Or you can read a tone into it that is unpleasant.  It's not good. But you have to assume, the only way to deal with this is to assume that  the reviewer, whoever is telling you stuff about your code, they're just trying to help.  They're trying to help make your code better, make you better, make the company better, whatever  it is they're trying to help or they wouldn't bother commenting. I'm not saying to tolerate  bad behavior, but bad behavior is a pattern that you can observe. One time thing, you  have to assume good intentions, otherwise you'll go crazy.  Now, a way to deal with this problem is, leads to helping others help you. Not everyone is  good at it, like I said, but some people are exceptionally good at just talking. So, if  you're having an interaction in text that is not working, then jump to video. Like, this  is my failure mode all the time, is I never go to video. But if you go to where someone  communicates well, then you will have good communication with them. Right? It kind of,  right, stands to reason. And instead of making people come to you, you should also be specific  in the feedback that you want. If you put up a portal quest and say thoughts, you're  not likely to encourage good feedback. So, if you actually specify, like, what are the  areas of your code that you want someone to, like, look at? Like, oh, this variable name,  I had a hard time coming up with it, I don't know, does this make sense? Or does this method  like make any sense? Could someone sort of, like, help me understand does this look right?  So, that does several things. One, it lets people, like, quickly figure out what to do  and can more easily engage with you, which means that you will engage with them. And,  you know, that kind of builds trust. But it also shows a little bit of vulnerability, which  is huge for building trust, because it shows that you're willing to acknowledge areas of  your code that aren't perfect. And so, then when people interact with you, they know that  they're getting an honest and authentic experience, because you're willing to call out things that  aren't perfect. Okay, code. Asynchronous communication. So, all this coding stuff is a form of asynchronous  communication. It's very specific to our profession. But you're also going to interact with people  not about code, writing emails, sharing documents, texting in Slack or something like that. There's  all kinds of asynchronous communication. And this is the primary way you're going to communicate  with most people, just by nature of being remote. Fortunately, this is a little easier  to deal with. So, communicating frequently and clearly. You have to provide more context.  So when you're talking to somebody, you can see their eyes start to glaze over, you can  see them get confused, they can raise their hand, they can interrupt you if you're not,  like, making a point. But in an email or a document, like, you're not going to get that.  You might never know if someone understood an email that you sent. So you need to provide  a little bit more context to increase the chance that they are going to understand that. So,  explicitly state what problem you're trying to solve or what information you want or what  you want them to do and why give some more back story so that there's a chance that they  get what you mean. You should also become a better writer because you're going to be  writing a lot. And this is how to do that. So you write something, you want someone to  read. The least you can do is read it yourself first. And when you do that, you find all  kinds of mistakes in your writing. You find all kinds of incorrect words and other things.  So everything that I write, I read at least once and I revise at least once because there's  always a way to make it better. And I just do this all the time. And as you do this more  and more, you make a habit out of this, then you will do it frequently and the more important  an email might be or whoever you're sending it to, you will revise more and more. And  it just makes you more effective at communication when you're sort of at least taking it for  a dry run. Typography matters. A wall of text is impossible to understand. Like hit return  a few times, make some paragraphs at least. Every few sentences there should be a paragraph  or something. But bold, italics, underline, like those exist, they have meaning, you should  use those. Bullet lists, I mean it's stupid to say any of this but I remember in my youth  every email was just nothing but courier text wrapped at 80 characters and if people wanted  bold then that was their problem, right? That is not the way to effectively communicate.  Again, the diagramming thing is really helpful especially when you're communicating to outside  developers or people who are not good at processing text which is lots of people, learn how to  make diagrams quickly and efficiently and that's a tool that you can bring to bear and make  things more clear. Being responsive. So a lot of the things we talked about with code  kind of apply here. The point is you want to engage, give feedback if you're being asked  for it, ask for feedback if you want it, like engage so that you're interested in helping  someone solve their problem. Because when you do this, this is how you get agency and  this is how you have an impact, right? And this is why being responsive is so important.  You have an opinion about things and if you don't share that opinion with anyone then  that opinion is not going to affect anything. It's just an opinion that you have. But if  you share your opinion with people then that is a chance for you to affect how things are  and if your opinions are good and they are helpful then you will be seen as someone who  is good and helpful. And that is, that means people will trust your opinion and trust you  and come to you and ask you for things and give you more of an impact on what you do  and that makes a much better work experience. So being responsive and helping people out  is good. But don't forget affirming feedback. So all the stuff we've been talking about  about feedback is like critiques, this is wrong, fix this, blah, blah, blah, it's very  easy to get wrapped up in that and we do want those. That is the critique that we want because  we want to be better. But it is nice when someone tells you that the thing you did is  good and it's even nicer when they say it in a very detailed way. So if you say, oh,  that API design looks good. I mean that's nice, that's very nice. But if you say the  names you're using in the route map exactly to the domain which makes it really easy for  me to understand this whole thing is like really simple. Thanks for putting this together.  That is really great to hear because it shows that you've understood what they've done and  that you took the time to say something nice and it's if you're a person that says nice  things to people and makes them feel good, that builds trust. So I used to think affirming  feedback was pointless, it is not pointless, it is very, very pointless. Assume good intentions.  So a lot of asynchronous communication you have as a developer will be with non-developers.  Sometimes there are people that use ask as a noun or use solution as a verb and if you're  like me it drives you completely insane. But the point is that's just a communication  style, it's not an indicator of ability. So I choose and this is hard but I choose to  assume that everyone I interact with is killing it at their job that they're really good at  their job. Because that mindset is the only way to deal with other people otherwise you  get wrapped up in communication style. I mean the number of power points that I have had  to have a conversation about in the last four years is kind of staggering but that's how  some people communicate and that's cool because they're good at their job and that's fine.  But help others help you. So again, kind of same deal, ask for the feedback that you want.  The other cool thing about this is this is another avenue to give context to help people  understand what you're doing. If you're telling them what you want that helps them figure  out what it is you're trying to accomplish and is much more likely to garner some back  and forth. So this is the hard, for me anyway this is the hardest part, is synchronous communication  which basically means being on some sort of video conferencing system. Why? I mean part  of it is I'm an introvert and so this saps my energy to have conversations but another  part of it is that it's this weird uncanny valley version of having a conversation with  a real person, right? Because you can see them and you can hear them but everything  between you and them is terrible software that barely works and the whole thing is just  awful. And so it's just more stressful to have to deal with this but some conversations  cannot happen over text. Like you have to have synchronous conversations sometimes.  So how do we deal with this? Be prepared. So I find if I'm expected to like say words  to people the more confident I am in the subject matter the more likely I am to say something  that makes sense. So read the material before the meeting. See who's there, what is the  meaning about? Do you have an opinion about what we're going to discuss? If so formulate  that opinion in your mind at some level of detail so if you have to say something it  will make sense and people will get it. You should also try to speak with more nouns than  pronouns. When you say stuff like he, she, it, they, this, that, thing, things not a pronoun  but you know what I mean. Those words don't mean anything. Who knows what that means?  The only way you can know is if someone said a noun before and you have, you can guess  that that noun is the thing that that means and okay now I get what you're saying. And  when you're talking to a person like face to face you can see them get confused and  be like ah okay sorry this is what I meant blah blah blah. When you're on a video you  can't see that. Also due to technology you will not be heard. Everything you say is not  going to be heard. Someone coughs, a word is going to drop out, two people start talking,  there's crosstalk, people aren't going to hear what you say. The internet drops for  a microsecond and one word goes. I've been on video chats where I missed the noun because  of technology and then for two minutes people were discussing and they never used a noun  and I literally couldn't figure out what they were talking about and I had to interrupt  and say what is the noun please. I don't know what this means. I'm sorry you've got to tell  me. So when you do that that means that the things that people do here they're more likely  to know what you're talking about. A better way is to pause frequently and ask for feedback  right because people can't interrupt. Interrupting on video is very hard. People aren't going  to necessarily do it. So take a moment. Okay. This is my proposal for how we're going to  do this JSON thing. Does that make sense everybody? And then you have this pause. When  we do our all hands engineering meetings at such fix like I said a lot of us are remote  and our CTO is really good at doing this. She'll give us information and then she will  pause and say anybody have any questions and then if nobody in the office has questions  she will always say anybody on the phone have any questions. And then pause for a very uncomfortable  amount of time because she knows that it takes a while for us to oh do I have a question?  I do have a question. Let me ask that question. That takes a while. So she puts those pauses  in there so that nobody has to interrupt and everyone has a chance to participate. So when  you're speaking you should do that. Being responsive and setting boundaries. This is  kind of the other end of this. For me this is the absolute hardest part. It's not multitask.  So if you are in a conference room with people and you're on your phone or you're on your  laptop like that's very rude and so you wouldn't do that because social norms say I got invited  to a meeting I should pay attention to the meeting I shouldn't be on my phone. But when  you're on a video conference you're literally on your computer and stuff is popping up and  you can check email and Slack and you can do these things. You can tell yourself that  you can multitask but you're not really paying attention and then either you miss things  that are important or you get called out. I have definitely been asked questions in meetings  where I have no idea what to say and I just had the cop to it. I'm sorry I was multitasking  please repeat the question. That's super embarrassing. When you do have something to say it is very  awkward to jump in but sometimes you're going to have to and because of all the delays that  happen you may have to ask the group to backtrack and just be up front about it. Hey I'm sorry  to jump in here real quick but can we go back for a second. I had this thing and this comment  like it's hard to do this. Some people just can't. I have a hard time not as hard as others.  The pausing thing that I talked about if others are doing that that helps and when you do  have the floor that is your time to set an example on explicitly calling on other people  especially people that you know are not going to be comfortable jumping in but you know  have an opinion. That is a really good technique. Oh Chris you just did this thing what's your  thoughts right or anyone on the phone else have something before we move on. That's how  these meetings should be run and so you have to set that example whenever you can. No one's  going to know that the AV is a problem but you. This is like when someone has something  on their teeth you just have to tell them because no one's going they're not going to  know so you have to be comfortable pointing it out. It sucks but that is a fact of life.  And of course you have to be self aware. These behaviors that I'm describing that kind of  have to exist on some level are jerky behaviors if they're done too much or too frequently  or too aggressively and so you need to have a lot of self awareness when you do this.  You've been asking people for feedback when you're offline to say hey I'm sorry I kept  interrupting you. I'm really not trying to talk over you but maybe I was like give me  your feedback on how that went so I can get better. Like yeah it's definitely hard. And  that sort of follows on assuming good intentions because people are going to interrupt you and  it's going to seem jerky and you have to assume that they're just trying to deal with the  technology. The other thing though is that the people who are maybe not remote who are  part of this who are in this mythical conference room they're not having a great time with  the video chat either. Like it's not great for them to have all of this stuff going on  and it is friction for them and having some empathy for them is really helpful because  it's actually something that you all can bond over. I complain about the technology all  the time and it's kind of can lighten the mood sometimes. Because computers are terrible.  You have to rely on all of these servers and all these pieces of technology and they all  barely work. I'm amazed it works at all. They don't work consistently. It's just all just  terrible. And acknowledging that can make everyone sort of feel a little bit better  about getting through the video conferences. Helping others help you. So I mentioned before  about the AV system issues. This will definitely happen and you need to kind of channel your  inner wedding coordinator and just tell people what they need to do because they're not going  to know. Hey, point the laptop at Pat because Pat is the one who's speaking. Just tell people  what to do. They're happy to fix it but they're not going to know because they're not experiencing  the AV the same way that you are. If you can recruit an ally or have a blessed back channel  that is really helpful too. So at Stitch Fix we do company all hands meetings and as I  mentioned a lot of developers are remote but there's a lot of other remote people. We have  lots of different offices. Our stylists are remote. People are traveling. So remote is  a big part of our all hands meetings. And there's a wonderful person on our ops team  who monitors the back channel and she asks questions for us and she fixes AV problems  and we can handle this all by chatting and not interrupting the meeting. So if you have  an ally that is super helpful. Okay, socializing. Why are we talking about socializing? You  go to an office. People know things about you. Even if you're the most private person  on the world and you never say anything to anyone, people will know what kind of clothes  you wear, what your hair looks like, how tall you are, what time of the day you come into  work, how often you go to the bathroom. These are banal silly things but people will know  them about you and if you are not going to an office they will know absolutely nothing  about you. I'm amazed at the height of my coworkers when I first meet them. It's not  what I expect ever. So what this means sadly for the introverts is you're going to have  to make small talk. You have no other way to interact with people and when you're on  these video conferences, especially with the West Coast, people are going to be late and  so you have a lot of time to kill. You're waiting for everyone to find the conference  room and get there. So make small talk. It sucks but you can talk about the weather.  It's the beginning of a conversation, a beginning of a personal connection. For me it's easy  because I live in D.C. where we have weather. San Francisco, they don't have weather so  it's always an evergreen topic. Another thing that we do is we do one-on-ones with people  that aren't our manager or aren't our direct report or anything like that with no particular  agenda. So I have a lot of one-on-ones with people where we'll talk about work sometimes  but we'll also just chit chat. Sometimes it's just five minutes but it's a time set  aside to interact as people as best as we can and it feels awkward to schedule these  sorts of things but it's the only way to make them happen and it feels normal after a little  while. Being responsive and setting boundaries. This is more about travel. Getting together  with people helps replenish this trust a lot. It is really handy if you can do it. Travel  is a pain so you want to make sure you understand what are the expectations hopefully before  you take the job. I guess I'm saying this because you might not be told what the expectations  are because it might not occur to someone that travel is difficult for you or something  like that. So be clear about what the expectation is and try to do it when you can. I mean a  lot of us work remotely because travel is difficult or we want the flexibility to run  our lives in a certain way and travel sort of disrupts all that. It's totally true and  definitely set boundaries but if you can travel it is worth it to reestablish those bonds  with the people that you work with every day because you do refresh that trust by seeing  people in person. Assume good intentions. Right. So people are going to make a small  talk with you too because they're going to want to know who you are and they might ask  things that are uncomfortable and they're not trying to be nosy. They just want to get  to know who you are. If you have things about your personal life that you don't want to  talk about that's totally normal and totally cool but that's all the more reason to do  that whole small talk thing. If you're driving the chit chat then you can drive it in the  direction that is safe for everyone. And just be okay missing social events like happy hours.  My respect and admiration for my coworkers is not derived by the number of beers I have  shared with them. It is by the good work that we do as a mindset I take and so therefore  I don't care if I miss happy hours or social events. I enjoy them when I can make them  and it is nice to have a beer with my coworkers but many of them I've never socialized with  at all and they're still great people that I love to work with. You just have to sort  of be cool with it. But it doesn't mean you can't socialize at all or you have to miss  everything. What it kind of means is that it might not be clear what those things are  and if you have ideas bring them up. You'd be amazed at how successful you can be by  bringing your boss an idea that requires your boss to do absolutely nothing but say yes.  You do that you're good. But it does mean you've got to take the initiative there. If  you can find a way to have in-person meetups, be creative about it. There's a couple of  developers live on either side of our Dallas warehouse and every once in a while they will  go to the Dallas warehouse and work together. They don't work on the same project but they  get to see each other in person and have a little social interaction. Be creative and  bring them up and suggest them and often your boss will be happy that you're helping to  figure this problem out because they're not going to know how to make the experience good  for you. All of that are tiny little things that all build little bits of trust between  you and others. When you're trusted and you work with people that you trust, you are going  to be way more effective at your job, way happier. You're going to have much more agency.  You're going to be producing much more value. You're going to feel included and the whole  experience is going to be much more rewarding. That's it. These are the four mindsets again.  Be frequently and clearly. Be responsive but set boundaries. Assume good intentions and  help others help you. I have just kind of described how things are in my company and  so you should come work for us or just talk to us and we'll tell you how this is and we  can give you all kinds of details on how this stuff works for us. That other link is for  these slides that you can check out if you like. Thank you.  The question is when there's social events and there's business talk, you're missing  out on that and that's a potential thing. That is absolutely a problem and that's sort  of a company culture thing. It's hard to fight information happening that you aren't even  aware it's happening. That is tough. Getting to know the company culture before you make  decisions helps and asking about that directly sometimes is the way to do that. That is potentially  a problem for sure. What's the good frequency for visiting up with people? When I started,  I did every two months because I was new and I knew I had to put a lot of effort into making  it work and that was helpful. Right now, the team gets together every three months. For  me personally, I do that but then I end up going for random other things in between. Everyone  comes every three months and that seems to work pretty well. Thanks a lot, everybody.
The_Effective_Remote_Developer_2_0_311.png The_Effective_Remote_Developer_2_312_539.png The_Effective_Remote_Developer_2_540_2111.png The_Effective_Remote_Developer_2_2112_2399.png The_Effective_Remote_Developer_2_2400_3107.png The_Effective_Remote_Developer_2_3108_3395.png The_Effective_Remote_Developer_2_3396_3623.png The_Effective_Remote_Developer_2_3624_4055.png The_Effective_Remote_Developer_2_4056_5507.png The_Effective_Remote_Developer_2_5508_6143.png The_Effective_Remote_Developer_2_6144_6755.png The_Effective_Remote_Developer_2_6756_6947.png The_Effective_Remote_Developer_2_6948_7715.png The_Effective_Remote_Developer_2_7716_8795.png The_Effective_Remote_Developer_2_8796_9335.png The_Effective_Remote_Developer_2_9336_10643.png The_Effective_Remote_Developer_2_10644_11423.png The_Effective_Remote_Developer_2_11424_11891.png The_Effective_Remote_Developer_2_11892_12227.png The_Effective_Remote_Developer_2_12228_13163.png The_Effective_Remote_Developer_2_13164_14219.png The_Effective_Remote_Developer_2_14220_14351.png The_Effective_Remote_Developer_2_14352_14891.png The_Effective_Remote_Developer_2_14892_15167.png The_Effective_Remote_Developer_2_15168_24215.png The_Effective_Remote_Developer_2_24216_25559.png The_Effective_Remote_Developer_2_25560_27515.png The_Effective_Remote_Developer_2_27516_28163.png The_Effective_Remote_Developer_2_28164_33683.png The_Effective_Remote_Developer_2_33684_34763.png The_Effective_Remote_Developer_2_34764_35327.png The_Effective_Remote_Developer_2_35328_36299.png The_Effective_Remote_Developer_2_36300_39887.png The_Effective_Remote_Developer_2_39888_43367.png The_Effective_Remote_Developer_2_43368_44723.png The_Effective_Remote_Developer_2_44724_46139.png The_Effective_Remote_Developer_2_46140_46979.png The_Effective_Remote_Developer_2_46980_48503.png The_Effective_Remote_Developer_2_48504_49727.png The_Effective_Remote_Developer_2_49728_51119.png The_Effective_Remote_Developer_2_51120_52307.png The_Effective_Remote_Developer_2_52308_52871.png The_Effective_Remote_Developer_2_52872_53087.png The_Effective_Remote_Developer_2_53088_53639.png The_Effective_Remote_Developer_2_53640_53687.png The_Effective_Remote_Developer_2_53688_54323.png The_Effective_Remote_Developer_2_54324_54419.png The_Effective_Remote_Developer_2_54420_54467.png The_Effective_Remote_Developer_2_54468_54695.png The_Effective_Remote_Developer_2_54696_54935.png The_Effective_Remote_Developer_2_54936_54995.png The_Effective_Remote_Developer_2_54996_55151.png The_Effective_Remote_Developer_2_55152_55188.png