My last week of the OpenSource phase

Hello everyone is being a long week, too things to complete in a very short time. First of all, let me wish you Merry Christmas and a Happy New Year, 2020 has been a hell of a year, but we have made it until here, so it's not time to give up, on the contrary, is time to keep going and pushing, better times will come very soon.

This week I kept learning a lot, and definitely, there is something that I caught until now, that is that in the software world you never stop learning, all the time you need to learn new stuff or maybe to learn an update of a feature.

On Tuesday, I had a pair with my one of my mentor, and it was very good, especially because we didn't code, and even like that I learned a lot. He taught me how to attack an issue from a project you never have seen. Usually, I just used to ask if I could contribute to solving an issue, and when they answered me I started forking the project and tried to solve the issue, and of course, I always bumped my head against the wall, and that was because it was very difficult to understand the whole project, I am not saying that you can not solve an issue without knowing the project, but most of the times you won't, because maybe something that you will solve, will affect other docs that inherit from the one you modify.

So what he told me is that first I need to know whats the objective of the whole project (read their documentation), after that we can see what are the conventions of the language and the project.

The next step will be to understand the issue, where is going to be used the code that I will fix or implement?, in case that the issue is a bug, how will I reproduce it? Once we know that, we can start coding, and when we think we are done, we need to ask another question, What are the acceptance criteria?, with this I meant what are the checks that say that the issue is fully fixed? Does it pass the test that the project has? is the issue not reproducing any more?

And when we will want to make a Pull Request, we need to see if it pass our own quality standards, you know sometimes one has his own kind of writing code. Then we need to see if it fits with the conventions of the projects (Prettier, EsLint, etc…). Then to make the PR you need to investigate if there is a convention in the project of how a PR is made because we need to facilitate the work to the people that are going to help us review the PR.

Once we made the Pull Request, we need to keep an eye on it, to see the updates, sometimes they will tell you to make some changes, or maybe it will crash at some checks, and we need to make some corrections. So in a few words, we need to stay alert to any comments on the PR and repeat the process.

I said all this because, for the issue from the Mongoose project, I don’t understand the project at all, that's why it is turning very difficult, and I talked with the staff of the project, and together we came to the conclusion that this issue was not a good first issue because for this one you need a lot more of understanding with the project, so right now we are in talks to try to solve the issue together, the only situation here is that they are on holidays hehe, so the communication is not that quickly but I won't give up, and keep, trying to solve the issue.

I also learned a lot more about Closures in JavaScript, I thought I knew the definition, and I did, but I didn't understand at all how it works. So for my post at Nearsoft jobs, we needed to make a post o software, so I decide to do it from a theme that was not very clear to me, here I leave you the post so you can check it out and understand better how a closure works, it is in Spanish but I can help you understanding or translating for you if it's necessary.

Well thanks so much as always for the attention, my best wish for the next year, see you in 2021.

Happy New Year!