Um Welcome to collaboration as strong Ali to overcome the unknown. This session is about experiences, me and my colleague, Tama ahead working together while working from home during the pandemics. And we know this sudden changes have been a challenge for everyone.We are all struggling to adapt new ways of work and we want to share a bit of what worked and didn't work for us and our experiences. So hopefully, it will inspire other people first. Let me present myself. My name is Bamber. I'm Brazilian. I work at Brazil's Office of Cadence Design Systems and I've been at Cadence for three years. Now, the first two years as an intern and this last year as a full time software engineer, Cadence works in the electronic design automation domain and I've been working with Jasper Go our form of verification tool. And I also called as a hobby creating. This is art of art with tools like processing and doing some creative coding. So now let's start with a bit of context. We had a big project, we were working in collaboration with um an important customer and at some point, we needed to work in some graphic user interface or G I features and we had a commitment with them. So we had a hard and also somewhat short deadline.

And the issue here is that not me, not anyone in my team had experience with GUS, we work in the core of the two. So we usually construct C++ API S for other teams to use it and construct their features on top of them. And in an analogy with web development, it's like we've always worked with back end and now we suddenly needed to work with front end. So it was a whole new world for us, but we had to do it. So we needed to learn by doing and spoiler. The project was a success. We were able to deliver in on time and with quality, the customer was happy and collaboration, teamwork was really essential for us to overcome the challenges and being able to achieve these results. And now I want to talk a bit about the process and how we achieve this and bear in mind that it's not a receipt, it's how it worked for us, but we've tried it and it may not work for all teams or for all types of projects. But we think there is value learnings and it's worth sharing first. Let me talk a bit about our usual workflow. Usually when we have a big project and multiple people working on it, we will split it into tasks and share these tasks between the people involved. Each one will do their tasks and together they will become the final result. And obviously, this is an oversimplification. There are processes thy caps and dependencies. So obviously, every project has its amount of collaboration.

But what differ here and what makes us need collaboration even more is that we didn't even know how to start. We didn't know how to break the work into tasks because we didn't know what was necessary to achieve the features. We wanted what was independent, then we could break and how to estimate the efforts for each task. And we did have these challenges first because we didn't understand the basics. We, we've used QT here as a user interface framework, but we didn't know the basic structure of QT.

We didn't know what were the basic data types and how to use then what to put in each structure, how to interact with them. But it wasn't only about the basics. We, it wasn't only needed to study, read the docs, read tutorial examples. And then we could construct our own small piece of software because here we needed to integrate it within a much bigger software. And that means for example, simply knowing how to edit existing going. But also we wanted to be consistent with the existing features and we needed to reuse some existing code. But our data came in different ways from different places. So we needed to adapt to the existing structures and much of them use advanced features of the framework. So with this uh scenario, we had to stop and rethink how it would work. And first thing we did then was to study, to search for knowledge and study here includes, for example, the things I've already mentioned about reading the docs reading tutorials and obviously sharing this knowledge between each other because we both needed to understand it and to be on the same page.

But it was more than that, we went through the code, we dig through the code together, we went on calls and was gonna investigate and read code, do some tests, really investigate and understand what is happening. How is this code being used in our tool to understand what we were doing and what we needed to increment and improve? We also did ask for external help and I have mentioned before that no one in our team had experience previous experience with G I. But luckily for us, we do have people in other teams with experience and they were really willing to help and were really helpful. And one thing I think it's important to mention about asking for help is that after the initial investigation, it was much easier for us to know what to ask, to have more direct and specific questions. We started to understand the structure and create the vocabulary about this framework and also being together, made it a bit easy to do something that is kind of subjective and always a challenge which is to know when you are struggling too much doing together and it's the time to stop and ask someone else for help.

So after some iterations of investigating and getting external help, we did finally start to implement our own piece of code and we started it with fair programming. So two developers working on the same piece of code and preprogramming and changing roles. While your pre programming is much easier when working in an office, we don't need special tools, just need two people to sit in front of the same computer and work together. But even though it's easier, uh it wasn't a practice in our team even before working from home. But here we understood that we needed to start together because we were still learning. We still had lots of struggles and it was faster to help each other and go out of these moments where we were getting stuck together. And also we were building the basic skeleton of it over two of our features, we were constructed the basic pieces to build on top of that. So it was still hard to break into pieces. And we both need to be at the same page here at some point, we were able to go back to splitting the tasks. And now we, what's more, much more about the refining and doing some specific tasks on top of this basic skeleton. So it was easier to split it. But one thing that is different from our usual work flow and that we did here was to still be in a call and just continue in a call and work together both in your separate task about the same project.

And then we, if any of us have a question, has a stroke or a comment, we would do it at the time and if necessary share the screen, which was something that we also use as per programming and it will, we could solve the problems much faster being together and also we could freely talk.

And that would kind of simulate the ambience that we have a do. That is something that we value and miss a lot. And finally, I want to mention code review and code review is established a practice in our team. We always use it and we value it. But I want to highlight it here because in this context of learning a new thing, uh code review from people with more experience, the same people from which we ask it for questions were really important. They were able to give us some important tips. And also even though we presented in a linear A, there was it interactions, we wouldn't do all of the code and then send to review, we would do it in steps and their help was important for us to keep in a good direction. And by the way about code review Tamara who worked with me in this project, uh has a session later today about it and I highly recommend watching it too. So that's it about our process. And as I said before, we did present it in a linear way, but there was a lot of iterations of investigating and asking for help and then going back again to investigation or also with the coding and then going to code review. But that is the general idea and the general practice that we've added to our work flow and that helped us. And now to conclude, I want to talk about our key points first is share knowledge fast to ramp up new domains together.

I think we tend to think that if you have two people working on the same project and the more efficient way is to split it into halves, then each one will do half of the work and we will complete it in half of the time. And in some cases, it is the case. It is a practice that reviews it at the end of the project. But when we are learning, when we are starting to construct the things we've noticed that we struggle in a lot of moments, we get stuck in a lot of moments and being together, we could go over these challenges much faster and thus ramp up much faster than we would do separately.

Also share connection, reducing, working from home solitude. I've been talking a lot about being on calls. We did it when we were investigating it together, when we were doing pair programming. Also, when we were simply coding and keep kept in a call to help each other. And I think we all have the sensations that we are in too many calls. We have too many meetings now that we are working from home. And I think it's important to note so that the experience here is different from, for example, having severo meetings, subsequent meetings during an afternoon here, we were actually working together and engaging in an activity and it was an activity of code in which what we like and want to do and doing it together, helped us to have someone to talk and not be alone, be closer to what we have at the office and not just alone all day at home, working and shared a load, two heads think better and more realistically than one.

I think one important thing about sharing the load when we work with more people in one project is about share the pressure about having a hard deadline and knowing that you have someone to help you achieve it. But also I think together we could think better and share some some decisions that are kind of subjective and sometimes hard, like the decision of when we are struggling too much with something and we should ask someone else for help or when we are doing a lot of investigation, a lot of learning.

But really we need to continue and start to implement code and maybe go back to other investigators later. Also, when we were at a time that we were able to construct sufficient piece of software together with their programming and we should go to splitting tasks. Again, these are all things that are hard to quantify and have a objective moment of when we should change. But and I think it will be always a struggle in every project but being together helped with it and share experience in individuals with different levels. Contributing to the same goal, Tamara who worked with me has more experience than me on in this area. And also at cadence and working with someone with more experience in itself. I think it's a really valuable experience having this hands, hands on experience with other people.

You can see how this person approach coding and debugging and acting and you and you get stuck and learning in itself and it's a really valuable experience. But also here we were both beginners. So even though we had different levels of experiences, we were both learning here and we could both learn with each other. Um That's it, that was our experience. It's something that we are, we've learned a lot, have some struggles but could achieve the results. And now we are trying to apply it to other projects and it's not something that we do all the time. But I think it's really valuable when we are learning something new. For example, when we have new hires or, and we have, when we have someone changing domains or simply needing to learn something new, how we did here. Um That's it. Thank you for watching. We have, you have my contacts here, feel free to contact me if you want to talk more and we still have a bit of time. So let's see in the chat if you have some questions. And OK, uh also, since we have a bit of time and no questions yet, one thing that I forgot to mention and I think it's relevant about doing pair programming while working remotely, as I said before, it is easier.

When we are at the office, we don't need any special tool and we did try some special tools. We did try an extension of VS code for collaboration, but we couldn't set it up and we've realized that we don't need really fancy tools. We just enter in a call and share the screen together and that was enough for us and it was really helpful. Well, that's it. Thank you for watching. Bye.