Firefox Feature Development in 2012

This year we started talking about ways to improve the methods in which develop Firefox features. This is a snapshot of where we’re at, and what’s coming next.

We began with some conversations about current problems regarding coordination, speed, contribution, regressions, ease of development: my initial dev.planning post, Joe Walker’s post ‘How to Eat an Elephant’, my blog post, dev.planning add-on bundling post.

There was general recognition that the Firefox development model is not agile nor flexible enough to meet the needs of our 2012 goals. We need to be able to ship features that are developed mostly outside of what’s considered the “core” Firefox team. We need to better support the use of external code repositories and bug tracking systems. We need to support features written using the Add-on SDK, both inside and bundled with Firefox.

Here’s where we’re at:

• A group of people formed to start discussing how to make these things happen: the Jetpack Features group. We meet every other Friday (meeting details and notes).
• We have a project branch (Cedar) where we can experiment and do performance testing.
• We corralled the Firefox and Toolkit module owners and the leads of the SDK project in a room to orchestrate the mechanics of landing the SDK inside Firefox itself (notes).
• L10n: The Jetpack team are hard at work on closing this gap with both localized strings in script and localization of HTML content inside add-ons.
• Performance: Jeff Griffiths blogged recently about the performance impact of the core SDK runtime on startup time. More performance tests are coming.
• Feature bundling: The BrowserID feature will likely ship in Firefox as a bundled add-on. There are still open questions though: Is it uninstallable? Does it even show up in the Add-ons Manager? Can it upgrade outside of the Firefox dev cycle? More work to do here.
• Automation: We have the Jetpack unit tests being run with every Mozilla-central check-in (though hidden by default currently). We have the SDK unit tests running on every SDK check-in for both Nightly and Aurora (tree). We still need the Mozilla-central unit tests run on every SDK check-in (that’ll come with integrating the SDK into Firefox), and performance tests run for Mozilla-central and SDK check-ins.

What’s coming up in 2012:

• Completing the picture of addon-as-feature integration into the Moz-ecosystem: l10n, performance and unit test automation.
• Ship BrowserID as a bundled add-on.
• Ship the SDK inside Firefox (the relevant parts, anyway).
• Ship Web Apps as a bundled add-on, if it makes sense to do so.

Resume review.

A friend recently asked me to take a look at his resume. After reading countless resumes and doing hundreds of interviews for Mozilla over the last 5+ years (whoa, almost 6 now!), a bunch of stuff came jumbling out. With his permission, I’ve copied the feedback here. Maybe it’ll be of use to someone looking for a manager’s eye on their resume. Most of the comments make sense on their own, so I didn’t copy the resume itself here.

Hey! Overall, looks good – you look like a solid candidate for a Java programming gig, with some potential for leadership, but not interested in it. Probably a senior coding member on a team (given the # of years experience) or a lone-wolf programmer that a manager could hand a project off to and expect you to run with it.

A couple of thoughts below with my critical hat on, ranging from grammar to technical. Please take with many grains of salt – obviously I’m not representative of all hiring managers. Also, I didn’t have the context about whether this is tailored for a specific position, or if you are just getting ready to hit the market. Is the resume tailored for your ideal job, or the job you’d settle for? Hard to evaluate without that context.

• My biggest criticism is that your personality doesn’t come through, only your technical skills. Everyone has a list of current/former employers, a list of acronyms, and *some* have a list of side projects (you get points for that in my book). The summary is your first chance to personalize what is otherwise an abstract description of a skill set, so take advantage of it. For example, you could start with “I am a lead developer” instead of “Lead developer”. Honestly, do you really talk in robot language like that in real life? No. Would you want to work with someone that did? Probably not. So, look for any opportunity to be more than just a developer of code.
• Clarify if you’re looking to lead or not, or even open to it. For me, this will contextualize my technical assessment of a candidate. Are you interested in project management? Are you interested in people management? Your resume currently says no, that you only want to code, but can work with non-programmers as necessary.
• “My main focuses are…” – is both redundant (focus implies main-ness) and misapplied (focus shouldn’t ever be used in the plural, by definition, IMO). Could say something like “My core responsibilities are…”, etc. You use focus later in a similar way in the Objective section: “expand professional focus” to include some other languages. That’s the opposite of focusing 😀
• I’d take “SOAP/RESTful” out of the summary, is overly specific, not necessary.
• “often responsible” – Nah, you *are* responsible for that stuff. No need to lessen your impact with qualifying adjectives, especially in your resume of all places.
• The Objective section seems to say that you want more variety in your work than you currently have, and that you’d like to learn a few specific programming languages. Is that about right? It sounds like you’re bored. That isn’t bad, but that’s the impression I get. Again, what to put here really depends on what your actual objective is. Is it to get a job writing re-usable Java libs for web front-ends? Or a job writing Python scripts against big data-sets? You should decide that up front, and be as clear as possible about it. If you need two resumes, so be it.
• The bits about the actual work you did are great. Instead of just listing the thing, you explain the impact that the thing had, the long term result for the business, etc.
• If you have degrees from those college years, note them. The multiple year sequences you were at Acme College don’t provide value, could just pick one or aggregate into one period where it makes sense.
• Needs a spell-check and grammar pass (eg: devloping, importanly, colloborating)

Final thought: What questions would I ask you after reading this resume, when we did a phone screen? What are things not called out explicitly in a resume, but are part of an experienced developer’s toolbox… IOW, the stuff that shows you know not only how to write code, but to *ship* software.

• I’d probably ask a couple of technical questions of medium difficulty, just to confirm that you can talk comfortably at the level of technical knowledge described in the resume.
• I’d dig into problem scenarios like the hardest problem you had to solve, both architectural and bug-wise. What tools/patterns you used, etc.
• I’d ask about performance problems – triaging them, debugging them, what tools for profiling, potential bottlenecks, etc.
• I’d ask about your testing and validation approaches, what unit test toolkits you’ve used, what automation you’ve written.
• Would ask you to describe your launch processes – things like staging servers, failover scenarios, backups, etc.