Reflecting on OSD700
For the last 4 months I have been working on various Firefox bugs. A few of them have gotten landed, I’m still working on others and some were too hard to finish, so it’s been an interesting ride. The tickets that I’ve worked on have been the following:
- Bug 702161 – videocontrols.xml has anonymous function event listeners that are added but never removed
- Bug 680321 – Media preload state should reset in resource selection algorithm
- Bug 708814 – Should fade out videocontrols even if there’s no mouse movement
- Bug 686370 – Implement video playback statistics proposed in WHATWG
- Bug 722788 – JSON number parsing is slower than it needs to be
- Boot to Gecko working on my phone
Since I began working on open source projects over a year ago in OSD600 one of the biggest barriers to entry for me has been IRC. It always sounds simple to just go into IRC and ask for help but a lot of the time it can be a pretty nerve racking experience. It can be scary to just throw yourself into the middle of a chatroom full of sometimes hundreds of developers better than you and ask what is probably a trivial question. When I first began doing this I ended up being afraid almost every time, thinking I would be labeled as an idiot for asking such an easy question and from that point on that no one would take me seriously. In reality my experience has been quite the opposite, in that everyone is friendly and willing to help out a newcomer. I don’t know why this is, but I attribute it to the pay it forward mentality, someone helped you in the past so you are likely to do the same for a newcomer that comes to the channel looking for help. I’ve actually taken this to heart and try to do it when I can, whether it be in Popcorn.js/Butter.js or Firefox bugs, I try to help people/newcomers whenever I can because I know I was once in the exact same position. I’m sure it’s just as hard to them to come into channel and ask a question as it was for me and I want to do whatever I can to make that experience more pleasant.
I have learned quite a bit this semester, from being more humble and stepping aside from my ego, to gaining confidence in both my coding and public speaking. It’s taught me some interesting lessons when it comes to coding. Until this semester I have always tried to rush through things, brute forcing my way through code in fast trial and error type approach. I would figure out what the problem was and then begin frantically removing, altering, and adding code as I went along. Most of the time when I figured out what was wrong I was left with a warpath of broken and ugly code in my wake, something I’m sure my reviewers in Popcorn.js/Butter.js can attest to as I’m notrious for leaving things like console.log( “ASDASDASDASDASDFAS” ); in my code. I learnt this lesson the hard way in one of the more recent bugs I was working on, 708814, which needed to be fixed up as it bit rotted for almost a month. I took a quick glance over my code and from what I could see it looked fine, I mean I also got an r+ on it, so it can’t be wrong, right? I went on what was a 20+ hour journey in the wrong direction, looking for a bug that didn’t exist. It was a stressful experience to say the least, one where you just want to grab your computer, shake it violently, and yell “WHY AREN’T YOU WORKING”. I asked for help in channel and no one else was able to see a bug either. At this point I was spinning in circles in my chair and looking at the same 8 lines of code over and over again not understanding what could be wrong. Sort of jokingly I switched my listener from “mozfullscreenchange” to “mouseover” and changed the if condition to check if the video was fullscreen or not. This was basically the same approach as I was doing, just in a different fashion. To my surprise it worked, as it looked like a fullscreenchange event was being fired before a mouseover event, and this was why it wasn’t working. In the end it boiled down to me having 0 patience and rushing into the code. I didn’t even take a second look at my code and began smashing my face into other code and assumed to problem was there. If I took 10 minutes to go over my code and think about it again I probably wouldn’t have done this. The only real reason I figured this problem out was because I am stubborn and didn’t give up, but if I learned to be patient before hand I probably could have saved a day worth of work. In order to work on code as large as Firefox you are going to need to be able to persevere and be stubborn, the code is going to beat you down over and over again and you need to show it who’s boss. I’ve been pretty good at not giving up this semester, but I didn’t really learn how important it can be to take a step back and be patient with my approach until I saw how far off I went in the wrong direction with 708814 ( and it was really far ).
In general the semester was great, I got to write in a language that I am far from comfortable with, engage with an unfamiliar community, and land fixes in Firefox. I continually tried to challenge myself with the bugs I undertook and I learned a lot because of it. I’m working on getting the video statistics ticket up for review by thursday and then working on review failures from then on. I think being able to say “I wrote feature X for Firefox” is a pretty awesome and is definitely another notch on my programming belt, so that’s what I’m striving for.
I had a great semester with everyone from class and I can’t thank everyone enough for the great feedback during class presentations and the help on irc. It was also great to witness everyone else step it up a notch and see what they got done, it definitely motivated me throughout the course to keep going and not give up. I wish everyone who graduated this semester ( I think everyone except me haha ) the best of luck with whatever you have planned for post graduation and hopefully we can all stay in touch via the seneca irc channel. To those who I’ll be working with over the summer at CDOT and Mozilla, I can’t wait to see what we make, it’s gonna be awesome!