My 3 year mozversary
A couple of days ago I started my 4th year at Mozilla and as with all anniversaries, it was a good opportunity to step back and reflect on my accomplishments during this past year and where I'm going next. And since Mozilla practices complete transparency, it also seemed like a good opportunity to sit down and write a blog post, as I never seem to get enough time nowadays to do so. Besides, what's the point of having a blog if not for embarrassing yourself every once in a while?
For a year with 4 different CEOs, the first thought that came to mind regarding my performance was: "a bunch of code, a ton of reviews". I didn't know if that was actually true though, so I set out to collect some evidence. All the code metrics I've come across must always be taken with a grain of salt, so I didn't worry about being completely accurate and I don't intend to gauge my progress on these metrics alone, but at least I wanted some quantification of the kind of impact that I had. Besides refactoring and bug fixing, my most useful feature work in this period includes break on DOM events, closure inspection, the memory actor and improved debugger behavior after a reload (edit: forgot to add the tracing debugger and function re-evaluation in Scratchpad).
The first interesting observation [1] is that I landed 63 patches last year, down from 139 the previous year, which was way bigger than the 56 patches the year before. This was somewhat disappointing and I believe that partly it was due to the initial debugger landing the year before and general work on an immature code base at that time, which made progress much easier to happen in small chunks. I find that I don't usually land separate patches for the same bug, so at least the number of commits is closer to the number of distinct bug reports or new features, than just individual code changes. Another reason for the decrease is that I spend significant time prototyping things that haven't landed yet, like the memory and performance widgets. Also, lately I find myself diving into SpiderMonkey and Gecko work for our upcoming memory and performance tools, and my lack of experience there slows me down considerably. Nevertheless, this is something that bothers me and I intend to improve upon this year.
The second observation [2] is that I'm doing more reviews as time passes, which is to be expected I guess. Last year I did 240 reviews, compared to 220 reviews the year before and 25 reviews in my first year. Obviously those who are around longer get to do more reviews than those who are new to the project, but what I mostly find interesting about this is that I get to do approximately one review per working day. Since I'm counting these from commit messages, they don't take into account the back-and-forth between the patch author and reviewer while shaping up the patch. I counted 372 review requests in my email during the past year (not including feedback or needinfo requests), so I seem to be giving reviews or feedback more like twice a day, every day. This must have contributed in part to the diminished number of patches that I landed myself, but on the flip side I get more visibility in incoming changes and can be more up to speed on my own work, which should decrease the turnaround for reviews on my patches. In addition to that, when I'm doing a review I'm looking at the patch from many different angles (from code correctness and code style issues, to API clarity and architectural direction) and that gives me insights into how our architecture should evolve, which in turn results in more followup work (incidentally, I've filed precisely 100 bugs last year).
Another very important realization is that even if I had spent exactly zero time reviewing other people's work, it would have been very unlikely that I could have managed to land all those 303 patches myself (240 plus 63 of my own). Which is another way to say that we all make a bigger impact by enabling others to do better work, than by strictly fine-tuning our own work output. This is particularly important for achieving a high bus factor for the project, but it is also a necessary ingredient if we want to nurture a community of contributors that will keep the project successful in the years to come. I find this sufficiently important and motivating that I don't plan to be doing less reviews, just try to invest my time more efficiently. We'll see how that goes.
Speaking of nurturing new contributors, I saw in a relevant dashboard that I mentored 8 bugs from 6 new contributors. I'm not sure about the time period of that data, but I've only heard about this dashboard recently, so I assume it should be relevant to this post. Clearly I need to do better in that department.
This past year I've also invested more time in giving public talks and helping with the Firefox OS launch in Greece. The social aspect was extremely rewarding and I've met a ton of great people, so I'd like to do more of that. Not sure how I could combine this with increased code productivity though.
All in all I feel it was a good year and I can't wait to see what the future holds. Onwards!
[1]: I used this command to count my patches (omitting the wc invocation allowed me to inspect the commit messages):
hg log -u past@mozilla.com -d "2013-04-26 to 2014-04-25" --template '{date|isodatesec} : {desc|strip|firstline}\n'|wc -l
[2]:I used the following command to count my reviews. Clearly searching for the right strings is a work of art:
hg log -d "2013-04-26 to 2014-04-25" -k ",past" -k "r=past" -k "r=panos" -k ",panos" -k "r=pastithas" -k ",pastithas" --template '{date|isodatesec} : {desc|strip|firstline}\n'|wc -l
For a year with 4 different CEOs, the first thought that came to mind regarding my performance was: "a bunch of code, a ton of reviews". I didn't know if that was actually true though, so I set out to collect some evidence. All the code metrics I've come across must always be taken with a grain of salt, so I didn't worry about being completely accurate and I don't intend to gauge my progress on these metrics alone, but at least I wanted some quantification of the kind of impact that I had. Besides refactoring and bug fixing, my most useful feature work in this period includes break on DOM events, closure inspection, the memory actor and improved debugger behavior after a reload (edit: forgot to add the tracing debugger and function re-evaluation in Scratchpad).
The first interesting observation [1] is that I landed 63 patches last year, down from 139 the previous year, which was way bigger than the 56 patches the year before. This was somewhat disappointing and I believe that partly it was due to the initial debugger landing the year before and general work on an immature code base at that time, which made progress much easier to happen in small chunks. I find that I don't usually land separate patches for the same bug, so at least the number of commits is closer to the number of distinct bug reports or new features, than just individual code changes. Another reason for the decrease is that I spend significant time prototyping things that haven't landed yet, like the memory and performance widgets. Also, lately I find myself diving into SpiderMonkey and Gecko work for our upcoming memory and performance tools, and my lack of experience there slows me down considerably. Nevertheless, this is something that bothers me and I intend to improve upon this year.
The second observation [2] is that I'm doing more reviews as time passes, which is to be expected I guess. Last year I did 240 reviews, compared to 220 reviews the year before and 25 reviews in my first year. Obviously those who are around longer get to do more reviews than those who are new to the project, but what I mostly find interesting about this is that I get to do approximately one review per working day. Since I'm counting these from commit messages, they don't take into account the back-and-forth between the patch author and reviewer while shaping up the patch. I counted 372 review requests in my email during the past year (not including feedback or needinfo requests), so I seem to be giving reviews or feedback more like twice a day, every day. This must have contributed in part to the diminished number of patches that I landed myself, but on the flip side I get more visibility in incoming changes and can be more up to speed on my own work, which should decrease the turnaround for reviews on my patches. In addition to that, when I'm doing a review I'm looking at the patch from many different angles (from code correctness and code style issues, to API clarity and architectural direction) and that gives me insights into how our architecture should evolve, which in turn results in more followup work (incidentally, I've filed precisely 100 bugs last year).
Another very important realization is that even if I had spent exactly zero time reviewing other people's work, it would have been very unlikely that I could have managed to land all those 303 patches myself (240 plus 63 of my own). Which is another way to say that we all make a bigger impact by enabling others to do better work, than by strictly fine-tuning our own work output. This is particularly important for achieving a high bus factor for the project, but it is also a necessary ingredient if we want to nurture a community of contributors that will keep the project successful in the years to come. I find this sufficiently important and motivating that I don't plan to be doing less reviews, just try to invest my time more efficiently. We'll see how that goes.
Speaking of nurturing new contributors, I saw in a relevant dashboard that I mentored 8 bugs from 6 new contributors. I'm not sure about the time period of that data, but I've only heard about this dashboard recently, so I assume it should be relevant to this post. Clearly I need to do better in that department.
This past year I've also invested more time in giving public talks and helping with the Firefox OS launch in Greece. The social aspect was extremely rewarding and I've met a ton of great people, so I'd like to do more of that. Not sure how I could combine this with increased code productivity though.
All in all I feel it was a good year and I can't wait to see what the future holds. Onwards!
[1]: I used this command to count my patches (omitting the wc invocation allowed me to inspect the commit messages):
hg log -u past@mozilla.com -d "2013-04-26 to 2014-04-25" --template '{date|isodatesec} : {desc|strip|firstline}\n'|wc -l
[2]:I used the following command to count my reviews. Clearly searching for the right strings is a work of art:
hg log -d "2013-04-26 to 2014-04-25" -k ",past" -k "r=past" -k "r=panos" -k ",panos" -k "r=pastithas" -k ",pastithas" --template '{date|isodatesec} : {desc|strip|firstline}\n'|wc -l
No comments:
Post a Comment