Last week, I wrapped up a summer internship at Mozilla, on the Gecko Rendering (Layout/Graphics) team. I worked out of Mozilla’s San Francisco office (visible towards the left of my picture above), a beautiful space overlooking the San Francisco Bay.
My main project for the summer was implementing CSS sticky positioning in the Gecko rendering engine, which forms the core of Firefox. I gave a short presentation on the topic in my second-to-last week (slides here):
This turned out to be a great internship project, being
summer-sized: manageable within 3 months (starting from scratch) but complex enough to take most of that time
relatively independent: not intimately linked to anyone else’s summer work, so I was able to take the lead myself
useful, but not release-critical: Gecko developers and web developers have been interested in this feature for a while, but there were no solid deadlines in anybody’s mind
This was really my first time working on a software development project on the scale of Firefox, and I certainly learned some things along the way:
There are many ways to solve a problem. Unlike with carefully constructed school assignments. At the same time, one can have a reasonable intuition about which approaches are (more or less subjectively) better. Several pieces of code I developed went through multiple stages of refactoring as I (and my code reviewers) tried to improve on that.
Existing code is not sacred: be bold. More than once I’ve been reluctant to add a new field to some existing class just to solve my small use case. Often that type of structural modification can be the simplest solution, and nobody is particularly attached to the details of the existing design. However, there is still lots of wisdom in code and people that have been around much longer than oneself.
Documentation is often not the best way to understand code. The Gecko
codebase actually has fairly good inline documentation, and also plenty of
wiki pages/blog posts/presentations giving higher-level overviews. Even
still, I spent quite a lot of time during the first month of my internship
trying to wrap my head around the machinery that is the 200,000+ lines of C++
layout directory. I probably should have bothered people with more
questions as I went, but it wasn’t until a couple weeks in that I could ask
anything very intelligent. After that point, conceptual questions were
usually best answered by another person with experience in the relevant code.
The people I worked/had lunch/chatted with over the course of the summer were wonderful—committed to what they do while being incredibly down-to-earth and friendly. Even though I chose Mozilla in part for the project’s philosophy, this amazing culture exceeded my expectations, and has set a high bar for my future job searches. While my mentor and several others from my team sat close to my desk in San Francisco, towards the end of my internship I ended up working more with people based in Mozilla’s Auckland and Toronto offices (via IRC and Bugzilla).
Also, the awesome “intern herding” team did a great job of keeping an eye out for all the interns, organizing fun events, and really fostering community—I know I’ve made some good friends who I’ll keep in touch with.
Although I grew up in the Bay Area, I had never spent much time in San Francisco before this summer. But I knew enough about the housing market to happily accept Mozilla-sponsored housing within a 10-minute walk (!) to the office.
San Francisco is a friendly and wonderfully quirky city. But I learned that downtown big-city life is not quite for me. I’m not sure whether it’s just the constant noise and bustle of Market St, or the difficulty of really escaping to nature (Golden Gate Park doesn’t quite cut it), or some combination of those and more, but the balance shifted from exciting towards stressful as the summer went on.
All in all, an excellent way to spend my summer. Thanks to everyone who made it possible!