Everything comes to an end, and this week marks the end of this incredible phase. I’m not completely sure if it was because of the holidays being in between, of if it was because of the pace of the work strategy of this phase, I suspect it was a mix of both; but the last month passed by incredibly fast, and while this phase was done in a blink of an eye, the experience and knowledge I’ve acquired throughout these weeks has been immense.

The main abilities I believe I’ve applied during this week are time management and the ability to understand other’s code. The former was practiced by the need of getting at least 4 Pull Requests by the end of the phase, which required me to calculate quickly an estimate of how long it would take to work out an issue, deciding upon this initial analysis whether or not I would be able to work it out in a reasonable amount of time, as it wasn’t a good idea to spend the whole month working on one same issue, both for the purpose of the phase and for our own sanity. Even after this initial analysis, I needed to be able to decide if after starting to work on a given issue for more than a day and a half, it would be wise to continue a bit more in order to finish it, move on to something else for a while, or give up entirely for times’/skills’ sake. I think this was an ability I hadn’t thought a lot about before the start of the phase, and while it took me a while to be able to decide the adequate course of action for each of the issues, I found it to be an incredibly important skill in order to maximize productivity and to not hinder progress throughout the phase.

The other important skill, learning to read other’s people code, was also an extremely useful ability to acquire, one which wasn’t as easy as I initially thought. After coming from the previous phase working on an already established project, I became confident that this challenge of the phase wasn’t going to be so hard… I was wrong. What I didn’t consider before starting was the fact that, last time, we had little over a month to work on the same project, plenty of time to familiarize with the ins and outs of the project. This time, we didn’t have that kind of time. The first weeks were pretty painful, as time passes and I found myself struggling to get even 1 PR, wasting too much time in issues that were either too complex, were not really issues but misunderstandings, or that I simply didn’t have the time or knowledge to propose a good solution. As the middle of the phase approached, I got better little by little, and by the end I could quickly understand at the very least the core ideas and approaches of most projects, as well as following the thread of logic for a given functionality in order to find and understand what the problem was. Looking back, I don’t think I ever saw myself capable of reading and understanding code as fast as I can now, being more of the “let’s start from scratch” mindset, and while I’m aware I still can do a lot better, I also believe I’m on a good track.

Another aspect from this phase that I would like to give a highlight is the open-source community. When the phase started, I was terrified of making any sort of contribution on any sort of big repository, being afraid that what I would do would be laughed at as just some amateur trying to pretend knowing what he didn’t. You can imagine my surprise when what I really found was a community full of supportive and helpful people, most of whom where incredibly happy to offer a hand or advice in order to help us contribute to the project they were all passionate about. The first PR I was able to close was an incredible experience, as I wasn’t really expecting such a grateful response to the work I had put on, this motivated me to also turn the other cheek and give my best attitude towards the community, extending a helping hand to anyone who I could. So yeah, while it might be obvious now, all I can say is that you don’t need to be afraid of being shunned for being an amateur, taking that first step and allowing yourself to be guided and embraced by the community is the best way to go.

With my general thoughts being laid out, I’d like to do a more concrete analysis of what I learned from each of my issues:

  • Meiliseach JS: This was the first issue I worked on, and the one that set me up on what to do and what not to do. For starters, this was the first issue I worked on that I was able to quickly identify what the problem was and the source of it, which was a good start. Unfortunately, I forewent the most important fact of asking for the exact data the issue was presenting with. This communication oversight led me to take a couple more days in order to close the issue, since I had to wait for the user who, fortunately, was kind enough to provide me the original dataset source.

  • Math.js: The second issue I worked on was fortunately pretty well documented, with the author of the repo identifying where the issue was. I thought I had a stroke of luck and had an easy issue on my hands, however I soon realized that I lacked the background to just jump in and start modifying code which I didn’t fully understand. At that point pressure was mounting, as I wasn’t able to get anywhere, so I decided to plough through and stick to it, spending a couple of days simply understanding how the library’s internals worked, as well as Linear Algebra theory required to fully understand the problem. I think this was an extremely positive experience, as I was able to go out of my comfort zone and experiment my limits, which contrary to my initial assessment where surprisingly farther than what I expected.

  • Open Library: The third’s issue main challenge was the fact that it was in Python, a language that I hadn’t touch in a little over half a year, and in which I don’t feel as comfortable as JS. The understanding curve of the project’s inner workings was therefore more of a challenge than what I expected, so it was an interesting experience overall. This PR also saw the first review request I got, which was an interesting dynamic that prepared me for the next PR.

  • Elastic UI: What I thought was going to be a relatively easy UX fix with Sass turned into an experience I wasn’t expecting, but one I’m grateful I had. First off, I underestimated the amount of work this would take, since I had to understand the way the cascading properties was structured within the project, then I had to understand some Sass commands I wasn’t familiar with, and finally I had to make sure I wasn’t modifying another element not relevant to the issue. The conclusion to this issue was an interesting one, since the PR that was merged resembled little of what I originally submitted, this as a result of the project’s team deciding to take a different direction with the solution I proposed. I was expecting the back and forth to become a little frustrating, but rather it was quite engaging, as I got invested in tracking how I could improve on my previous attempts, and at the end I understood the reasoning behind their decision and appreciated them being so open to some random guy like me. It was a longer experience than what I anticipated, but a welcomed one.

  • Vuetify: This contribution was made on a library I had previously used for acquiring Vue components. The issue itself was an easy fix, which led me to understand some Vue and even JS concepts I hadn’t understand (the fact that the logical operator in JS don’t always return true or false blew my mind). The main takeaway from this contribution however was the testing, since I discovered a new tool for frontend testing, that which is snapshots.

Looking back on this phase, I can say that I feel a lot more comfortable with working on other people’s projects, which at the end of the day was one of the main purposes of the phase. I also wrap up this chapter with a greater understanding and appreciation of the open-source community as a whole, something I hadn’t really give much thought before this.

Speaking of this and as a final note for this essay, this week I’ve been reading the this and object properties part of the You don’t know JS series. This week’s takeaways are:

  • The this keyword doesn’t refer to the function’s scope.
  • The this keyword doesn’t bridge the scope between two functions.
  • The meaning of this depends entirely on where exactly it was called.

That was a long essay for a short and fun phase. Let’s see what expects us next week!

Open-source