End of Semester

by David Humphrey

Like many of my colleagues working in education, for whom the next few weeks are busy with grading students' assignments or exams, I'm currently marking projects from my Mozilla Development course at Seneca.  I've been rereading student blogs and looking back at bugs, and started to see some common things emerging.  I wanted to share some of them.

The majority of my students worked on bugs in Firefox, specifically Gecko bugs related to the media element, DOM events, fullscreen, and pointer lock.  Because they were clustered together in similar areas of the code, they were able to help each other quite a bit, and talk with one another about struggles they were having, and celebrate when things got landed.  In general they each worked on 4-8 bugs, usually getting half of them landed by the end of the course, and therefore shipping in some future version of Firefox.  They ranged from Good-First-Bug type issues right up to full spec implementations, like Pointer Lock.

In no particular order, here are some of the observations I'm seeing again and again in their blogs:

  • Writing code to fix a bug is one thing, but getting the tests written, and passing on all platforms, is often much, much harder
  • You can't measure a fix in lines of code (loc).  Often a tiny fix can take dozens of hours to do, since you first have to diagnose the problem, figure out where things are going wrong, and plan how to solve it.
  • It's important to learn how and when to ask for help.  Trying to go it alone will end in tears and wasted time.  A well timed, intelligent question can short circuit your development time significantly
  • Similar to the above, it's easy to not ask for help because you think people will look at you like an idiot for asking such a simple question.  In reality that never happens, and people are very helpful.
  • It's not uncommon for a patch to go through a dozen (or two dozen!) versions on its way to shipping in Firefox: fixing a bug is only part of the process.  Reviews take time, testing takes time, landings (and backouts!) take time.
  • Working on large, complicated code like Mozilla helps keep you humble and aware that you don't know everything
  • Keeping a patch up-to-date with trunk, as it goes through reviews, can be frustrating.  Code that used to work, stops working; things you relied on change, or vanish.  You have to build in time for this in your development plan.
  • Getting things fixed and landed is really about being patient and not giving in too quickly.
  • Fixing bugs in Firefox gives confidence to go work on any other code bases
  • Until you've done this work, you have no idea how easy it is to say, "Why doesn't Firefox just fix X?" and how hard it is to actually do in practice.
    The other thing I'm reading again and again is that people feel a sense of pride, accomplishment, and increased confidence for having worked on Firefox.  Those are exactly the kind of outcomes I want in this class, and with this experience.  It's not possible for me to guarantee it, so when it does happen, it's rewarding to witness.

I'm indebted to many people in the Mozilla community who helped my students find bugs, did reviews and offered feedback on patches, helped late at night on irc, and generally were there to help my students succeed.  There are too many names to list, but I want to centre out Olli Pettay, Chris Pearce, and Jared Wein, who really went above and beyond.

This is my 7th year taking undergraduate students into the Mozilla community and having them work on real bugs.  It continues to inspire and excite me.  I would also say that things have only gotten better within in the community in that time period, in terms of Mozilla's willingness and preparedness when it comes to welcoming new (student) developers.

I'm looking forward to doing it all over again in September.