Out of Sight, Out of Mind: Survival tricks and tools for remote developers

Speaker 1: Uh It's very nice to be here. It's very nice to be here in Heidelberg. It's my first time at uh DjangoCon Europe. This talk I presented it in a slightly different way yesterday uh yesterday at uh uh PyCon in Florence and uh the funny thing about this talk is that One year to the next a lot of things changes and so it's very nice to to revisit. And We will talk about remote working. Remote working is a extremely big topic. We will just cover the tip of the iceberg. And uh I will try to make it short

Speaker 1: so there could be time for some questions at the end. And uh It's very nice to do it in a conference when there is streaming. Live streaming so there are people out there watching now probably remote developers so I would say hello to everyone who is a remote developer and is taking time out of the schedule to watch the konference from another location which is kind uh the point of the whole thing. So uh another thing is Towel Day. Uh I work for a company that has 42 in the name so we cannot just uh ignore it and Our company motto is don't panic , which is always a very useful thing to say and to keep in mind.

Speaker 1: The other thing is GDPR Day. So again, don't panic. It's very nice to be in such a theater. I it's probably my first time on a proper stage with a proper microphone and with all the technology. So it's uh it's tempting to feel like a rock star. I'm not a rock star. And uh so I would like to introduce a bit uh uh who I am and the people I work with because uh it's very relevant for um the kind of talk uh I'm introducing. Uh I'm mostly a web developer, always been in my career. And

Speaker 1: especially I work with uh Django and Python and that's the reason I'm here. As I said, I work with a company that has Agile 42 in the name. It's a coaching and training company and we are a very distributed company in Europe, in North America and in South Africa. And especially our web and IT team has an headquarter in Berlin and a number of people, including myself, that work uh remotely and in particular I work from Milan and not only I work remotely for this job but I used to do it also for previous jobs so I have a bit of experience in that.

Speaker 1: I've seen it all. I've also worked in offices so I see the difference. And Basically, the question I ask myself every day is how this is possible to do effectively and without too much stress. Um you know the dream. Uh the dream is to be an IT worker that uh works whenever they want usually from the from the beach with flexible hours living a very nice lifestyle Um but actually the reality is that uh you work uh out of a cramped

Speaker 1: space uh you work in not very good hours, you basically have all the problems of working in an office and none of the perks like chatting with your friends at the water kulor or a kapp of coffee. Not to mention that remote working has this kind of perils. Will it be still relevant today? Because but yeah, you you know what I'm talking about. So uh let's get a bit uh to uh the core problem that we may face.

Speaker 1: I took this quotation from an article that is linked there from Zack Holman. And I think it enkapsulatar very näcly the problem. What's the difference between a remote friendly company and a remote first company? A remote-friendly company is a lot of IT companies these days. You can do uh one or more days of work At home, you can take time off, you can do flexible hours. The result is Is what really counts and not the number of hours you spend in the office.

Speaker 1: But still there is an office and people who choose not to work in that office. A remote first company instead is a company that breaks the structure of the office work and creates a workflow That allows people to contribute in a more free environment and a more free structure. And that's really the challenge for this century. As I mentioned, we work in agile coaching. Agile methodologies, the whole uh culture of agile uh tries to help companies to work better and workers to work more effectively without burning out

Speaker 1: So we ask, can agile methodologies help remote workers or can agile methodologies help a remote culture in the company? We think there are a certain set of agile methodologies that definitely help uh remote working. For example, a culture of TDD, which means test driven development, which means that you create first a set of tests against which you run your code. Actually helps a lot remote teams because it sets a number of boundaries That don't just

Speaker 1: work because people share the same code intimately over the same keyboard, but in a more flexible environment. No code over ownership, the same. It's easier to work with a remote colleague if we all agree that a certain area of the code can be uh improved but all members of the teams and especially uh what we call uh visual radiators Meaning that you have structures that help understand what's the status of the project, like backlog, boards

Speaker 1: all kind of artifacts that uh you can either share in your office or uh in a virtual board But then comes the kicker. We know instead from experience and from work with companies that actually the most effective teams are the ones are co-located, meaning that they work in the same office. For example, in large American companies this they discover that not only they have to be on the same building but they have to be tied together. have nice offices

Speaker 1: uh far from each other, it's better to put them together so they can contribute more. That seems to break the whåra reason of remote working. This is a principle from the Agile Manifesto. And we know it's a few years old. right by now. And this says explicitly that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. So this looks like a problem. But I would like to parse these principles because It seems obvious from

Speaker 1: the face of it , and I think it keeps standing if you uh check carefully what it means. So for example, we should discuss exactly what we mean by face to face. Because In the good old days it was quite obvious to say that face to face meant some people in the office or even some people around the table. Some people around the table discussing the problems of a software project. But now we are in a completely different culture. Part of what face to face meant was proximity. You are next to your colleague, but also a sense of truthfulness.

Speaker 1: Meaning that What face-to-face was against was against thick documentation that moved from one level to another. large meetings when there is no real discussion and these kind of things that were common in enterprise development. So a face-to-face discussion not only means that we are standing with our bodies in short proximity, also means that we Talk to each other without a barrier and telling things exactly how they are. In the 21st century in 2018 we have a lot of this

Speaker 1: conversation in chats, group chats over electronic messaging You can be really true with your colleague in Slack and you can just say a lie face to face. So Slack, Skype, Whatsapp and Gout are now very common tools for teams. And this is 99 % of what face-to-face means in that sense. Of course, there is still an aspect of body language and the pleasure of interacting with each other that we we don't want to discount, but it's uh it's not the key part of face-to-face. And

Speaker 1: the reason to be face to face is to exchange information. So what can we call information uh in the area of a project development? Well the most obvious is discussion about the project So how we should do some things, how we should move forward and so on. Very specific details about the code. Very specific details about design. uh the artifacts that the development team does. And also you want to communicate to your team the things that worked, commits tasks done, the things that didn't work, all the bugs, all the regressions.

Speaker 1: And you want to chit-chat and grow that team culture that is very important for a successful project. Yes, this is all information and these are all things we talk to our colleagues about. Do we really need to be in close proximity to do this? Not necessarily because all these things you can for example rely on a Slack channel. Slack is very popular. skype, chat, or even gudding e-mail. Some of these things are actually better to be discussed online, especially if you

Speaker 1: Are talking about kod or design. Having a share screen helps you more than just disking it or at a meeting. So we go back to that article by Zach. Where he says that using a culture where everything you do is either manually or automatically pushed into a communication channel And for example, he mentioned chatbots, you know, uh a tool that takes an action from some other system and puts it automatically in your chat, then you create a culture Well, it's not important if you're in the office, it's not important if you're in the office that day, it's not

Speaker 1: important if in the if you are in the office ever Because basically we are all remote workers from different locations. Some of them accidentally are in the same office And we all contribute to the same project and to the same communication channel. So basically it's a cultural challenge rather than uh uh a plain old technical challenge. This is a new slide that I added a couple of days ago. There are articles from the enterprise side of things, from example from the Harvard Business Review.

Speaker 1: That start to talk about this change in the workplace. Where electronics Electronic tools are the glue that keep together a remote team. This is a uh a tweet from uh Lee Bryant, a researcher at PostShift. I suggest you check him out. He always write very interesting stuff. So uh One reason to do this at a conference like Django DjangoCon is to uh help

Speaker 1: teams and individuals that want to go down this down this path. So here I would like to to tell how we do it with our team at Agile 42. Uh basically we have a lot of shared stuff. We have a shared code repository and uh possibly this is reachable from the outside. So you know uh you have GitHub, you have Bitbucket. Some companies may have security issues. It's something you can work around. We have automated unit testing and integration testing. That's what I said that agile methodologies or plain old methodologies from extreme programming

Speaker 1: they come very useful because All testing helps create a safety net for developers, especially developers who don't have someone next desk to confront with. They can just rely on the structure and they can move their code forward in a more sustainable way. Of course we have continuous integration, which is pretty common nowadays, but helps us with contributing kod från different individuals who are not necessarily sink, especially in tim zones or in working hours.

Speaker 1: We have uh boards, we use uh all kinds of task planning and uh also we like to test a lot of things. All of this of körs must be available från any location, and all of this goes into a channel which is our main communication channel and the heartbeat of our project. But of course, you also have to adjust your personal style and the way that the team interacts with each other in order to make it work. Um you if you do agile

Speaker 1: uh methodologies and I strongly suggest you should do it. And you do your agile ceremonies starting with the daily stand-up with the sprint planning. the review, the retrospectives and whatever your method calls for. You do it online. You do it in a way that allows remote workers to attend and remote workers to contribute. For example, with my team we connect regularly over Skype. We even see each other. That helps with the uh distance barrier and we do our sprint reviews, we do our daily stand-ups. You should not work

Speaker 1: alone in the sense that you wake up in the morning, you just eck your code and you go to bed. You should contribute to the life of the project. You should say, I'm going to do this, I'm going to do that Oh if you are going to do that to a colleague then I can help or I think this is a better idea to follow up Uh one thing that I discovered in my career that is a bit against the whole dream of remote working is that having working hours that are compatible uh with the rest of the team, especially if you have some team

Speaker 1: some parts of the team that work out of an office and therefore they do something more closely aligned to nine to five or at least to be available around the time where you expect other members of the team to be online. And you have to keep that chat channel open during work hours. It's basically your way of checking in in the office and checking out from the office. I know that a major company that does remote working, full remote working, so we'd say remote first. has uh one of the few requirements is to keep the chat channel open during work

Speaker 1: hours Uh you cannot be remote 100% of the time. Um occasionally you have to meet If it's more than occasionally it's nice. The kind of interactions you have when you are face to face are different from the ones you have online. And sometimes they are just funnier or they just or sometimes they're just uh more forward thinking so it helps with the planning and so every remote team should just meet occasionally just to sync up and to put a face to the presence online. And of course there are a few companies, I just name two,

Speaker 1: that do remote first. They like to talk about it, they like to explain the tools they're using, and so it's a good source of inspiration. This is, for example, a screenshot. I understand that it's uh the details may be lost, but this is uh a screenshot from our own uh Slack channel of developers, and you see for example uh slack bot that reminds us of agile ceremonies like a stand up uh an error message from our integ from our um bug tracker. Trello which we use for lightweight project management

Speaker 1: sending out comments about um a work in progress and things like this. So uh and uh you see the comments you see for example um coming from from GitLab comments attached to a specific story they are pushed also into the channel. That's what we meant as chatbots trying to keep the communication channel alive and to put everything so we can comment on These are a lot of statuses from our um continuous integration project. And this is much more lively discussion about a certain feature, what we should do about it, and

Speaker 1: uh I can say that uh I'm not sure uh where the people were at the time. I was remote in Milan, but other people were probably on vacation and contributing a little bit. So this is the way we keep a project moving forward and Of course the they come from Slack which a lot of people are using these days for this. So um we are Using a lot of tools to do that, and these tools change constantly over time. We are constant continuously refining and changing. As we said we do test driving development and we use unit test, Selenium, we have a lot of visual tests to align

Speaker 1: uh with what we want to achieve. We try to do infrastructure as code , another layer that helps us get away from the uh concept of having a staging server and a test server. At the moment we mostly use virtual machines but uh Docker is a very nice solution. So Um I was very happy to hear from Lacey from the talk before. If I understand correctly, she's also a remote developer, so we see how all these techniques come together. And recently we've moved to GitLab , our own Osted

Speaker 1: GitLab, as a Git repository and project center for our development. This also allows us to uh use pipelines for continuous integration. tying even closer together the development, the project management and the continuous integration. Inside GitLab. At that point we integrated GitLab with Slack and with Sentry , which is a tool to alert of bugs. we created this chatbot that allows us to see almost everything that is

Speaker 1: happening in the project. We also moved project management to GitLab with boards and some Trello, which is always nice because it's very lightweight. As I mentioned we use Skype for the agile ceremonies and Google Docs, whatever. Basically we try everything that can be helpful for having a team that is not in the same office to coordinate and exchange information. Here I have a screenshot of a pipeline A pipeline is in GitLab is a set of tasks that you can do to test and build and install

Speaker 1: on either staging or development machine. And this is very helpful because it's triggered automatically by a commit in the repository and these allow us to work as a team and not having for example A person who is only tasked with code integration and code testing and therefore may be may feel detached from the team. As you can see here , sorry, we uh configured uh webhooks from GitLab into Slack to notify everything that's happening in the project inside

Speaker 1: our communication channel and therefore to be alerted about what's going on. One other tool that uh I wanted to mention is uh sentry, which is uh an add add-on to your code that alerts you of uh mi errors and problems and uh is configured to fill into the the Slack channel as well. So if we go back To this you see for example notification from Sentry that happen automatically on the channel and allow the team

Speaker 1: to talk straight away about what's going on if it's just a small problem or if it's a major problem and needs needs to be tackled. Here instead you see more notification about the kod and the integration av pipelines kommer från GitLab. uh all marked with the team member that contributing to that code allow us to give a sense of what's going on in the development at that specific moment. And uh so for example you see uh

Speaker 1: the great advantage of this approach is to intermix This automatic notification, from example from GitLab, with personal comments. This means that you don't have a separated channel. uh uh for um the the more technical stuff but it's all part of the team discussion and uh you can have a better sense of what's going on in the project without having to move from one project uh from one tool to the other. Um thank you. Uh I think uh I ran

Speaker 1: a bit fast uh because I'm always afraid of uh Uh going too late, so I'm open for questions.

Speaker 2: That's for you.

Speaker 1: Thank you.

Speaker 2: Um we have time for questions. Um

Speaker 3: Hey, hello. Uh hi, I am uh hundred percent uh full time reward worker. Um I don't do meetings in person. I don't go uh to see clients. The the only time I see clients is at uh events like this. And one of the things you said kind of uh bothered me and I wanted to uh know if you could um Tell tell more about this. Is that you said that you uh a lot of companies wanted the communications channel to be open uh during business hours? Or and uh Uh this in my experience is really bad because people see you online and they want to talk to you and so you don't have your time to concentrate and do your work. You're uh constantly interrupted.

Speaker 3: So do you have any guidelines that you want to uh Sure to to avoid this kind of problem.

Speaker 1: Yes, no, it's uh um it's an extremely good question, uh because it opens up a whole area uh which is kind of team management so what do you expect from your team members and so on. In this respect I don't think it's different from uh a team that is co-located in the same office. Uh you shouldn't assume that since your coworker is at the decks at the desk next to you is always ready to take questions and this basically happens uh in the same way when you're remote. Since you're remote you are not expect it to be available to chat at any moment because

Speaker 1: just because no you have a green dot next to your avatar or something similar depending on on the tool you use. One thing that I skipped over because it's a it's a whole other it's a lot of other things is You have to have a work in agreement with your team. A working agreement is a term we use a lot in in agile coaching And basically it starts with nothing, with a dampy piece of paper and can grow to be extremely complicated. The working agreement you have with your team is, for example, that you have uh you are online, uh it doesn't mean that you're available. Um you may

Speaker 1: Say on the channel well today I'm just doing lightweight work and so I'm free if anyone uh needs help or the contrary Usually you're free, but if you if today you're going to do something that really needs concentration, I'm not available for anything. I cannot give you exactly what's best The thing I can say is you have to talk about it in the team. Uh you have to come up with something that is probably written down because it helps just uh you have a shared document and you put down these rules. That's what we prefer to call it working agreement. Sometimes the rules are

Speaker 1: pushed down by management. That's unfortunate. Sometimes it's necessary Uh the uh the thing I said uh is yes management asked this as to have the chat the chat channel open. Is good or is bad? Well they probably have their reasons. It's something that is part of a discussion. Um and it's uh as part of an agile coaching company something that probably get a lot from us. I'm sorry, you have to talk about it. Uh because that that that's the key. No, you have to you have to define your own process Uh one thing uh um I can suggest more precisely one of the ceremony

Speaker 1: is the aj uh is the daily stand-up. It's uh common to most agile methodologies. And we found that it's very useful. Even if you and the rest of your team are working on different projects or different sub-projects, different tasks Even if you work remotely at even at different time zones, you should find a time each day to sync up with the rest of the team. So for example, myself and my team we do it at 3 pm each day and over Skype. If you're really busy uh with your project or from the task you're doing which is part of a larger project

Speaker 1: you should still find time to do these five to fifteen minutes And these five to fifteen minutes say to the rest of the team, I'm working on this. I'm sorry guys, I cannot help with anything else because I'm 100% focused on this. And the team should understand Then at that point if someone sets you up. Oh did you see that thing I said I'm sorry I said very specifically that today is devoted to this. So it's um Then we enter in the area of rudeness, which is a completely different thing. And since it's a ceremony and It's not when you have time but it's a fixed time each day you plan your day around

Speaker 1: it. So i if you know if it's first first thing in the morning or after a break and so on is not interrupting you because You plan your day around it, everyone gathers around either in person or with a tool And they tell each other how much they are available to help each other with the things I'm working on. Hope it helps.

Speaker 3: Thank you.

Speaker 2: There's another question at the back if you're up for that?

Speaker 1: Yep, definitely.

Speaker 4: Yes. Thank you.

Speaker 1: Yeah.

Speaker 4: You said uh no code ownership

Speaker 1: Mm-hmm.

Speaker 4: This uh resonated with one of my personal mantras, which is if you ride it, you own it.

Speaker 1: Okay.

Speaker 4: Which means um take responsibility. So how do you avoid if people are not allowed to own parts of the code, how do you avoid that nobody takes responsibility for problems that arise

Speaker 1: Well uh the the responsibility is uh is from the team. Uh if you work in a team and uh uh our idea is that we always work in a team rather than individuals Of course if you're if you're being subcontracted to just work on a specific piece of software and uh um uh you're the only one really working on it and so things may be different but in most cases you work on a project as a team The code is owned by the team, the team has responsibility, and individuals within the team may take action on a specific part of code, on a specific task, always saying to the rest of the team, we are doing this because of this.

Speaker 1: I've chosen this solution because of this. Other members may contribute or may even change it, giving explanations. Now If someone from your team entering the code you've been working on for six months at very astute level with a lot of good ideas. and put bad code inside it because uh it didn't understand what you were trying to do and commits it Then again we enter the state of rudeness. It's a problem within the team. It's a problem

Speaker 1: that uh your colleagues are not up to the same level of quality that you have and you should have a discussion with them about this. So I understand, since I I I always had a career as a developer, how we feel about the code and the artifacts we have developed. Without entering into the world of code reviews and also pair programming, which is very useful and now basically can also be done online in in a number of ways. You should always be up for discussion and review of what you've done with the rest of the team.

Speaker 1: And in this respect, the responsibility of what the cloud does moves from yourself personally to the whole team. I don't know if it's the answer you wanted to hear.

Speaker 4: No, it's exactly what I wanted to hear. Thank you.

Speaker 2: Okay, that's one more question in the front.

Speaker 5: So uh I wanted to add to the first question. Yes sir. And uh I think that like one of the most common problems with tools like Slack is uh defining What has to be real-time communication and what can happen offline. It's like so imagine I have an issue I want to talk to someone. It's like a lightweight meeting. We chat for five minutes. That works. But if there is something that requires somebody's attention and doesn't have to happen immediately uh then an email is probably better or a ticket on whatever. So my question is how do you define the things that can go on slack and things that you probably better not put on slack because then they will be buried by five hundred more messages and

Speaker 5: it was something that could have waited and it's better if you deal with it like once a day when you look at all your emails or tickets or whatever.

Speaker 1: Yes, sure. No, I uh as you probably notice from from my hair, I'm not exactly uh a freshman out of college. So I I grew up with email and I still f uh find that emails is an extremely valuable tool. You can express your uh point of view, especially about design of code or a project, much more clearly and allows for um Also for a bit more time to articulate your message. So uh my co-workers get a lot of emails from me. You know, it's uh uh I'm active on on the company's leg but they get more emails and sometimes they say Oh, it's one of those long emails from Alessio again and they say well um

Speaker 1: uh how what uh which is my you know boundary between slack you know real-time communication and email I think uh uh the synchronous asynchronous evaluation is the best one As I mentioned, I have a rough feeling of the time my co-workers are in the office or they are active. I don't know for sure, especially you know, 5 p. m. is he in, is he out or whatever, but I have a rough idea. So um Uh I don't slack at evenings, uh Saturdays and Sundays or things like that. And also I don't push

Speaker 1: long discussions over Slack. By definition a long discussion, something that I want to say about the project Doesn't need to be resolved in the next five minutes. It's something that can wait and can also have a longer discussion. And I um so I put it in email and I explain well Uh these are this is my point of view, we can discuss it. Or sometimes I say um if you have some idea just uh let's chat about it or Uh let's review it at the next stand-up meeting, which is always a good sinking point for this kind of this kind of stuff Uh no way. Nowadays I've uh uh I've moved to in

Speaker 1: even more asynchronous way Meaning that if I have something very long to say, I usually put it in a Google Doc, allowing other members of the team to comment and even edit what I what I've written. I use uh chats, basically now Slack, but in the past it was Skype and other tools First, when I um when I have something to ask to a co-worker of mine uh that would be in uh uh traditional office just moving to their desk and asking. So are you working on this?

Speaker 1: What are your plans for today and things like this or help help help The server has a system load of 120, and I ran out of ideas, and that's probably the best use for an instant message.

Speaker 2: Thank you.

Speaker 1: Thank you. Last slide, I will put them on slideshare. There are some links to thing I talked about and don't panic