 Hello everyone, my name is Sasha. As Michael has mentioned before, I am currently a junior developer at SP Digital. I've been working there for around three and a half months now. I'm a fresh grad, so before that I was a student at SCTD and before that I've only been going through internships and part-time jobs. So tonight I'll be sharing with you my experience with full request review as a junior deft in the past three and a half months. So, is everyone here familiar with what a pull request is? Can I have a show of hands, who is familiar with the concept of a pull request? Oh, okay. So a lot of people are familiar. But basically it's just a request to repository maintainers, too much proposed changes by you. But the biggest concept works is that you pull the changes, hence the name, pull request. Okay, so pull request allows for collaboration. If you have heard of open source software, not everyone might have the right access to the repository. So you must propose your changes through a pull request for it to be accepted to the code base. It also provides checks and balances. So even though you have the right access, you might actually still have to submit a pull request so that your peers, your colleagues, has to review your code just in case it can be improved for better. Now this is the form of a pull request that you guys might be most familiar with. It is how pull request. The title of this pull request is add install MongoDB role. It was submitted by somebody. There is the description of what the PR does. Usually each repository has their own template of what should provide when you are submitting a pull request. So please do read their contributing guidelines before submitting one. You have your changes. In GitHub, you can view those changes inside the files change tab. There's also a reviewer. And in this case, the pull request has been approved and it has been merged to the master branch. And then there is also another form of a pull request. This was taken from the Drupal issue tracker. But it's essentially still the same. You have a problem or the motivation of submitting this pull request. And you have a proposed resolution to this problem. There's some remaining task. The difference here is that instead of in GitHub, you might push your changes to the respective feature branch of Buffix branch. Here you submit patches. So patches is also another thing you can generate in Git, which is basically just hunts of changes. You know those things in files change that has the plus, plus, minus, minus. It shows you what you add and what you remove from the code. Those are essentially what patches are. It says here that the pull request need review. But this is just another form of pull request. And now the role of pull request in our developer journey. I think as long as you are still writing code, pull request will be an integral part of your journey. I think at first when we start writing code, our interaction with pull request will be that we are the one submitting the pull request. As a junior developer, especially we are expected to write codes. Usually our description is to be able to write some stuff in what language, in certain styles. So that's what our first interaction with pull request will be. With the rise of the open source initiatives and also events such as Hectable Fast, I see there's someone wearing the Hectable Fast t-shirt here. The interaction of the pull request has been facilitated. So a lot of people have interacted with it now. But then we expect as you grow and get more experience as a developer that you will then be given the responsibility of reviewing a pull request. And I thought at first that as long as you are still a junior developer, you won't be given this responsibility of reviewing a pull request because it has been consistent with my previous experience in my first internship. I was only tasked to write a code. So whenever I want this code to be merged, I will then request for a senior developer to review my code. And only senior developers essentially review intern's code. This was also true when I worked for Red Hat even though the team was quite small at the time. I have never been asked to review a pull request prior to this part of the job. But then in SB, I was asked to do a pull request one month in. And it was very scary to me at first because I know that pull request review is important because I think as a reviewer we ask some kind of guard that is guarding a gate to the code base. You are one who decides whether this piece of code can get merged into the code base or not. Now if you let something bad and you keep letting bad things come in, you will definitely decrease the code quality of your code base and it might lead to a lot of future problems you might let a bug go through and yeah, disaster. And then the reason why I was scared also is because I don't feel qualified to review a pull request. Prior to this assignment at SB, I've only been coding in Ruby on Rails and also in school I learned Python and Java and then at SB we mostly use Golang for our development so I had to learn this language on the job but then one month in I had to review a pull request written in Golang in a language that I had just learned so I totally didn't feel qualified to do it. And then I'm also not confident in my ability to communicate because when you are reviewing essentially communicating with the submitter about your feedback what could have been done better and basically it's just a way for you to communicate. Okay, but then I realized as I was doing my PR then in a PR you can do the obvious stuff which is you see whether it solves what it's trying to solve. For example, if you have a story tracker then a PR might take one story and then see if it implements the features that is required in the story. You can also, of course, check that there is no bug as a junior developer I think you can still try to read and find red flags if there is any even though you might not understand the whole thing fully. You can also check adherence to guidelines. Usually when you are working in teams you must have agreed on some guidelines to adhere to. For example, in the project that I'm currently working on we have a guideline of having code coverage of at least 70%. So in the pull request you can see whether this pull request fulfills that criteria. Does it decrease the code coverage? Is it now below 70%? If it's now below 70% then you can request for the submitter do more thorough testing to fulfill the guideline. And then there is also the not so obvious stuff that I have discovered that pull request can actually be a medium to do knowledge transfer because you actually are reading the whole changes that your colleague has made. So to do a thorough pull request you might even read their code line by line you try to understand what they are trying to do and you then will understand how the code works under the hood which is good if you plan to work on that project for a long time because then you will know how each part works and then when you have to work on it in the future you already have a context of how it works and then you also understand the reasoning of the other party because when you write code based on assumptions you might make assumptions oh, I assume A therefore I will write this code in a certain style but then your assumption might be different from that of your colleague so when you are reviewing you might think hey what is my colleague write this in this style or in this way and then what you should do as a reviewer when you face that kind of question in your head is that you ask the person why maybe you put your friend of thought I thought that this is like A but then what did you do in a certain style and then the other thing is also you check for I think this is the role that us as junior developer can play the most in because a senior developer might have written some fancy one-liner that is very not readable but then to us then suddenly you can't read the code but if you can't read the code then is it really readable enough then will it be easy for other people to get on boarded to your project can request for the submitter to write it in a different way but most importantly the lesson that I learned is that no one expects you to be perfect so this is what my senior developer told me when I told him that I was nervous about giving this whether I should approve this PR or not is it really within my rights to actually do it then he told me that no one expects you to be perfect it's fine if you can't do everything you can't catch every bug it's fine even if you actually accidentally let a bug in it's not your fault in fact it's nobody's fault it's not even the submitter's fault I mean what's more important is that you then find the bug and then try to fix it alright so these are also things that I've learned in a poor request you can, aside from doing all those things or you can also note things that are interesting to you this is what senior developer has commented in one of our project oh I haven't seen this package used before then he recommended another package maybe this is another interesting package you can try to look at it but you don't need to use it here you can also ask for clarifications I found something it's not really consistent with what the other packages has been doing and so I asked why it is so and turns out it was because of the library API that we were using the third thing that I learned is that you should not procrastinate on reviewing your PR because they tend to pile up it slows down your development also if you feel that I think it's better to ask yourself why is it hard to review this PR is it because it's too big then maybe because if it's too big to you then maybe you can request the submitter to actually split up into several small PR is it because the requirement is unclear then maybe it's time to ask why trying to solve or maybe ask your product manager about those stuff or it might maybe because you don't understand what the PR is trying to do and then you can also ask questions to clarify another thing that I've seen people do in the PR also you can actually refer the PR to someone who might have more context as I say it's fine if you don't understand everything if you think that there is someone else that is more qualified for example, this is a senior developer alright so he said that he is not very familiar with the stubbing style for this testing so I can't tell if it's written correctly or not so he would suggest maybe get another person more familiar with it to take a look too so it's fine to do that too and last but not least don't be afraid but don't be a jerk either so don't be afraid to leave your comments and leave suggestions and take any PR comments personally it's not a personal attack on you it's never unless someone is clearly trying to repop your food but don't be a jerk either don't try to destroy someone's work everybody makes mistakes so just be nice about it leave constructive suggestions and that's all any questions? any questions?