The Effective Remote Developer
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Teil | 49 | |
| Anzahl der Teile | 86 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/31291 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
Mailing-ListeSoundverarbeitungHilfesystemRPCSoftwareentwicklerQuick-SortOrdnung <Mathematik>DifferenteMereologieGrenzschichtablösungMultiplikationsoperatorProzess <Informatik>FlächeninhaltNeuroinformatikCodeDienst <Informatik>Office-PaketTaskDatenverwaltungGruppenoperationRechter WinkelWort <Informatik>BAYESPunktSoftwareMAPVertauschungsrelationXML
03:30
Dienst <Informatik>MereologieProzess <Informatik>MAPMaßerweiterungVertauschungsrelationSoftwareentwicklerInverser LimesSoundverarbeitungMultiplikationsoperatorBildgebendes VerfahrenGüte der AnpassungRPCOffice-PaketNotepad-ComputerModallogikQuick-SortTypentheorieUML
05:51
Gebäude <Mathematik>EnergiedichteQuick-SortRPCSoftwareRandwertVerschlingungHilfesystemDatenverwaltungGüte der AnpassungWeb logDefaultGeometrische FrustrationLeistung <Physik>RechenschieberAutorisierungSoftwareentwicklerSoftwarewartungGruppenoperationStellenringTVD-VerfahrenXMLUML
07:37
Chatten <Kommunikation>SchnittmengeGebäude <Mathematik>TermTelekommunikationQuick-SortPhysikalisches SystemDialektRPCVideokonferenzEchtzeitsystemEin-AusgabeWort <Informatik>Inklusion <Mathematik>InternetworkingNotebook-ComputerVollständiger VerbandSoftwareEinfach zusammenhängender RaumInteraktives FernsehenWeb logSoftwareentwicklerXMLUML
09:28
Prozess <Informatik>E-MailChatten <Kommunikation>MultiplikationsoperatorSoftwareentwicklerMereologieProdukt <Mathematik>Funktion <Mathematik>CodierungVideokonferenzComputeranimation
10:06
Prozess <Informatik>SoftwareSoftwareentwicklerMultiplikationsoperatorZeitzoneCodeSchnelltasteTelekommunikationInklusion <Mathematik>FlächeninhaltRandwertTypentheorieDiagrammRechteckMereologieMathematikRückkopplungBildschirmmaskeWort <Informatik>ProgrammierumgebungSchedulingApp <Programm>Güte der AnpassungFreewareReibungswärmeEinsNotebook-ComputerVollständiger VerbandProjektive EbeneATME-MailInteraktives FernsehenSchreiben <Datenverarbeitung>ServerElektronische UnterschriftMustersprachePerfekte GruppeSoftwareschwachstelleVollständigkeitKontextbezogenes SystemBitBildgebendes VerfahrenSoftwaretestMAPExogene VariableMinkowski-MetrikSchreib-Lese-KopfSoundverarbeitungProdukt <Mathematik>VideokonferenzPhysikalische TheoriePhysikalischer EffektEndliche ModelltheorieInhalt <Mathematik>UmwandlungsenthalpieRechter WinkelStandardabweichungFigurierte ZahlHilfesystemGrenzschichtablösungBitrateUnrundheitQuick-SortResultanteCASE <Informatik>Computeranimation
18:21
AsynchronbetriebNatürliche ZahlCodeGemeinsamer SpeicherInteraktives FernsehenCodierungIndexberechnungE-MailBildschirmmaskeNichtunterscheidbarkeitProzess <Informatik>Leistung <Physik>Logischer SchlussGradientenverfahrenWort <Informatik>PunktTelekommunikationMultiplikationsoperatorZahlenbereichKontextbezogenes SystemMailing-ListeRechter WinkelRückkopplungArithmetisches MittelInterrupt <Informatik>Mixed RealitySoftwareentwicklerHilfesystemInformationQuick-SortDomain <Netzwerk>Schreiben <Datenverarbeitung>DiagrammGüte der AnpassungUmsetzung <Informatik>AggregatzustandExogene VariableBitXMLUMLComputeranimation
23:33
SoftwareUmsetzung <Informatik>MereologieVersionsverwaltungEnergiedichteVideokonferenzSynchronisierungQuick-SortPhysikalisches SystemXMLUML
24:12
Notebook-ComputerMAPVollständiger VerbandFigurierte ZahlE-MailMultiplikationsoperatorNeuroinformatikPunktVideokonferenzWort <Informatik>ComputerspielKoordinatenEinsStochastische MatrixNormalvektorInterrupt <Informatik>Innerer PunktNichtlinearer OperatorMereologiePhysikalisches SystemRPCHilfesystemChatten <Kommunikation>BitInternetworkingServerOffice-PaketQuick-SortGüte der AnpassungRandwertGruppenoperationSoftwareentwicklerTropfenInformationRückkopplungReibungswärmeRechter WinkelMomentenproblemArithmetisches MittelInverser LimesVererbungshierarchieDifferenteExogene VariableSprachsyntheseSocketFreewareLeistung <Physik>Dreiecksfreier Graphp-Block
30:45
MultiplikationsoperatorOffice-PaketXMLUML
31:19
SoftwareentwicklerProjektive EbeneRichtungInteraktives FernsehenMultiplikationsoperatorQuick-SortErwartungswertBenutzerschnittstellenverwaltungssystemProzess <Informatik>ZahlenbereichGüte der AnpassungComputerspielEreignishorizontVerkehrsinformationRandwertVideokonferenzExogene VariableDatenverwaltungUmsetzung <Informatik>DatensichtgerätEinsFigurierte ZahlHilfesystemWechselsprungEinfach zusammenhängender RaumRechter WinkelLie-GruppeGruppenoperationFastringUML
34:52
BitTopologieProzess <Informatik>Güte der AnpassungHilfesystemGeradeRandwertXML
35:23
Quick-SortFrequenzRechter WinkelVerschlingungInformationRandomisierungHilfesystemEntscheidungstheorieEreignishorizontRechenschieberPlotterInstantiierungVorlesung/Konferenz
36:40
JSONXML
Transkript: Englisch(automatisch erzeugt)
00:13
Well thanks, thanks a lot for coming. My name is Dave Copeland, or Davetron5000 on Twitter, and I'm gonna talk about how to be an effective remote developer, I hope.
00:22
So I spent the last four and a half years as a remote developer. I was one of the first engineers at Stitch Fix. We're a personal styling service for men's and women's clothes, and when I started, we were very small, scrappy startup kind of thing, and I was just writing code as one does in that situation. But due to the way we work at Stitch Fix,
00:41
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 Stitch Fix, vendors that we rely on, all remotes for that entire time.
01:02
And that's pretty typical of a developer at Stitch Fix. We now have over 70 engineers, and most of the engineering work at Stitch Fix 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.
01:22
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.
01:41
It's not a great sentence. I tried very hard to make a better one, but I think this gets the point across. You go somewhere and do work. Maybe that's somewhere as a coffee shop. Maybe that's your basement. And you work with people, and those people aren't there most of the time. So that's the situation that I mean by remote. And if you think about it like that,
02:00
there's a lot of remote work happening in the world, not just with developers. So there's the lone wolf. 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 gonna 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. Everyone just sort of works whenever, wherever.
02:22
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 your 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.
02:42
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 wanna be working on something valuable, right? You wanna 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.
03:03
You also wanna have some level of agency, right? You don't want your job to just be closing JIRA tickets all the time. You wanna 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 wanna feel included.
03:20
You wanna feel like part of the team. You don't wanna be, again, the person whose job is just to close JIRA tickets. You wanna 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 wanna imply that you get these things for free
03:41
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
04:01
to make sure that stuff happens. And that's what we're gonna talk about. There's not a week that goes by that I don't think about the remote experience that I have or that 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
04:23
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.
04:42
I don't have to commute anywhere at all. I can make lunch in my kitchen. My kitchen is in fact stocked with these 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
05:00
is I don't have to live in San Francisco. I love, love not living in San Francisco. 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.
05:20
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.
05:40
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 gonna talk about Slack or anything like that. You have to spend your energy building trust
06:00
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 gonna 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.
06:21
You can go to the slides later. It's a blog post by Steve McConnell. Steve McConnell's 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,
06:42
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. 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
07:00
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. We're gonna talk about those with respect to all the different things that we do as developers.
07:20
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 gonna talk about things that you can do to do that but we do have to have a brief chat about technology.
07:40
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 gonna need a few set up. You're gonna 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
08:01
not developers, right? So it's gotta be something that every person that you need to interact with is gonna be able to deal with. IRC is not that thing, I'm sorry. You're gonna 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
08:21
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, right? No, WebEx meets this 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
08:41
because you just sort of need to pay money and get them set up and I don't wanna 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
09:01
which is very terrible because all that that entails. It's not the same as talking to a person 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.
09:21
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 I outlined these kind of four mindsets. So I wanna talk about the kinds of behaviors that they could drive when you're doing different things
09:42
that are part of your job. So we code 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. Coding, that's a thing you're hired to do. That is the thing that makes you a developer
10:01
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
10:21
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 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
10:42
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 gonna see that frequently and they're gonna be able to understand it
11:00
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 because you have to think about it, not just am I getting the code to work but can someone understand what I've done
11:22
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 wanna optimize the way you work so that people can understand that because you're not necessarily gonna have another way to talk to them. The only communication you might have is the change request, whatever form that takes. So if you're thinking about redoing the test
11:40
because they're not RSpec enough, don't do that. If you're thinking about refactoring this ugly code that 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 at Stitch Fix, we make pull requests to GitHub, whatever your process is, you're presumably
12:00
gonna 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
12:20
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.
12:41
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
13:00
than typing a bunch of stuff out. I use this thing called Jing. It's free for five minutes or less. You can share the 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's the same way. Just buy OmniGraffle and learn the keyboard shortcuts and then you'll make diagrams very quickly and easily and then that is a thing you can bring to better communicate with people.
13:24
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 gonna do it. So you need to help them. So there's a lot of ways to do this
13:40
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 try to be nice about when 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. Don't know if you know this. I'm on the East Coast. Can we do this later, right?
14:01
So it's a very nice way to kind of set some boundaries without 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 gotta take off. Let's pick this up in the morning, right? But you do need to set those boundaries because people aren't gonna 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 say, yeah, cool
14:22
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
14:41
by giving you feedback. If someone reads your pull 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 gonna 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
15:02
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, 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
15:22
and that is gonna 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
15:41
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
16:00
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 getting their code commented on? Is that a fun experience? Okay, yeah, it's very harsh. We as an industry aren't used to critiquing each other,
16:22
we're not used to being critiqued, we're not good at it on either end 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's telling you stuff
16:41
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
17:03
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. This is my failure mode all the time is I never go to video but if you go to where someone communicates well
17:20
then you will have good communication with them. It kind of 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 pull request and say thoughts, you're not likely to encourage good feedback. So if you actually specify what are the areas
17:43
of your code that you want someone to 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 make any sense, can someone help me understand, does this look right? So that does several things. One, it lets people quickly figure out what to do and can more easily engage with you
18:00
which means that you will engage with them and 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.
18:20
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 gonna 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 gonna communicate with most people
18:41
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 making a point
19:01
but in an email or a document, you're not gonna 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 backstory so that there's a chance that they get what you mean.
19:24
You should also become a better writer because you're gonna 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
19:41
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.
20:02
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,
20:21
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
20:41
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 wanna engage, give feedback if you're being asked for it, ask for feedback if you want it, engage, show that you're interested in helping someone solve their problem because when you do this, this is how you get agency
21:03
and this is how you have an impact 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,
21:21
then you will be seen as someone who is good and helpful and 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.
21:41
So all this stuff we've been talking 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
22:01
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 if you're a person that says nice things to people,
22:20
it makes them feel good, that builds trust. So I used to think affirming feedback was pointless, it is not pointless, it is very, very point. 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
22:43
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.
23:01
I mean the number of PowerPoints 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. 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.
23:22
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 heart and for me anyway, this is the hardest part is synchronous communication which basically means being on some sort of video conferencing system.
23:44
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 it's this weird uncanny valley version of having a conversation with a real person 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
24:01
and so it's just more stressful to have to deal with this but some conversations cannot happen over text. You have to have synchronous conversations sometimes. So how do we deal with this? Be prepared. So I find if I'm expected to say words to people, the more confident I am in the subject matter,
24:22
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 meeting 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
24:41
with more nouns than pronouns. When you say stuff like he, she, it, they, this, that, thing, thing's 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 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 face to face,
25:02
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's gonna drop out. Two people start talking, there's crosstalk, people aren't gonna hear what you say. The internet drops for a microsecond and one word goes.
25:24
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,
25:41
that means that the things that people do hear, 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 necessarily going to do it, so take a moment. Okay, this is my proposal for how we're gonna do this JSON thing. Does that make sense, everybody?
26:01
And then you have this pause. When we do our all-hands engineering meetings at SuchFix, like I said, a lot of us are remote and our CTO is really good at doing this, so 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
26:22
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. Like, that takes a while. And 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 and this is the, for me,
26:40
this is the absolute hardest part to 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 in the meeting, I shouldn't be on my phone. But when you're on a video conference, you're literally on your computer
27:00
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 to cop to it. I'm sorry, I was multitasking, please, please repeat the question.
27:20
That's super embarrassing. When you do have something to say, it is very awkward to jump in but sometimes you're gonna have to and because of all the delays that happen, you may have to ask the group to backtrack and just be upfront about it. Hey, I'm sorry to jump in here real quick but can we go back for a second? I had this thing, this comment.
27:42
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 gonna be comfortable jumping in but you know have an opinion. That is a really good technique.
28:02
Oh, Chris, you just did this thing. What's your thoughts? 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 gonna 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.
28:22
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. Sometimes you've been asking people for feedback
28:42
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 gonna interrupt you and it's gonna seem jerky and you have to assume
29:00
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. It is friction for them and having some empathy for them is really helpful because it just kind of,
29:23
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, right? Because computers are terrible. Like 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.
29:41
And acknowledging that can make everyone sort of like 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 gonna know.
30:03
Hey, point the laptop at Pat because Pat is the one who's speaking, right? Like just tell people what to do. They're happy to fix it but they're not gonna 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
30:20
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
30:40
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 in 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,
31:01
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
31:22
is you're gonna 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 gonna be late and so you have a lot of time to kill or 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
31:40
and it's a beginning of a conversation, a beginning of a personal connection, right? For me, it's easy because I live in DC where we have weather. San Francisco, they don't have weather so it's always an evergreen topic. Like, yeah. 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
32:02
with no particular agenda. So I have a lot of one-on-ones with people where yeah, we'll talk about work sometimes but we'll also just sort of chit chat and 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.
32:21
Being responsive and setting boundaries. So this is more about travel. So 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 wanna make sure you understand what are the expectations hopefully before you take the job and I guess I'm saying this because you might not be told what the expectations are
32:40
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,
33:01
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 gonna make a small talk with you too because they're gonna wanna know who you are and they might ask things that are uncomfortable and they're not trying to be nosy.
33:21
They just wanna get to know who you are. If you have things about your personal life that you don't wanna 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.
33:41
My respect and admiration for my coworkers is not derived by the number of beers I've shared with them. It is by the good work that we do as the 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
34:02
so 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 kinda 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.
34:21
You do that, you're good but it does mean you've gotta 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 sides 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
34:41
so 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 gonna know how to make the experience good for you. So all of that are tiny little things that all build little bits of trust between you and others and when you're trusted
35:00
and you work with people that you trust, you are gonna be way more effective at your job, way happier, you're gonna have much more agency, you're gonna be producing much more value, you're gonna feel included and the whole experience is gonna be much more rewarding. So that's it, these are the four mindsets again, communicate frequently and clearly, be responsive but set boundaries, assume good intentions
35:22
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 you can or just talk to us and we'll tell you how all this is and we can give you all kinds of details on how this stuff works for us and then that other link is for these slides that you can check out if you like, so thank you.
35:46
Yeah, so 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 and that's hard to fight, it's hard to fight information happening that you aren't even aware is happening,
36:00
like that is tough. Getting to know the company culture before you kind of make decisions helps and asking about that directly sometimes is the way to do that but that is potentially a problem for sure. Yeah, so what's the good frequency for visiting up with people? So when I started, I did every two months because I was new and I knew
36:21
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 and for me personally, I do that but then I end up going for random other things in between but everyone comes every three months and that seems to work pretty well. Thanks a lot, everybody.