I went to my first Hybrid Factoryevent with some of my teammates this past evening, which was kind of like a mini-workshop. The event was titled, "How to effectively work as a Tech Lead," given by Derek Parham.
One of the main topics was delegation: the audience interaction portion of the event asked us to consider how we would approach delegating all of our current tasks to other people on our teams.
During this exercise sstangl brought up something profound: rather than other Mozilla Corporation-employed teammates, how much of our current task load could we delegate to the community members outside of Mozilla Corporation (AKA MoCo)? These are the people who voluntarily devote their time and effort towards advancing the Mozilla project.
Of course, the talk also covered the classic "bus test," which asks, "If [person X] were hit by a bus, how would we continue to function?" It wasn't a big leap to my asking, "If all of MoCo were hit by a bus, how well situated is the community to carry our outstanding tasks and projects?"
Like all fun hypotheticals, it's far fetched and a bit apocalyptic, but it forces you to think about your team's work and coordination methods in a very different light.
I suppose a related, follow-up question is: if the Mozilla organization is designed to empower a worldwide community, but we couldn't survive a MoCo bus scenario, then are we managing the project in a sustainable way?
Maybe people who oversee the project as a whole (and those who are more familiar with the philosophy behind our governance) have a definitive answer. In any case, it's interesting food for thought.
Latest in the, "People problems are hard, I'm glad I just program computers," set of thought processes. If you have thought-provoking anecdotal data points, your comments are welcome!
There's a confounding and contentious dynamic in programming between collaboration and concentration. This goes beyond just individual and team efficiency — it's also about finding a balance that lets you enjoy and grow your craft.
There are certainly times that you want to hunker down in an LCD-monitor-adorned sensory deprivation chamber and do some badass debugging, find all the corner cases in that nasty algorithm, or suss out all the invariants in a complicated system.
But, on the other hand, there are certainly times that you need to write code during a flurry of peer interaction. If you're ramping up on a new system, the thirty seconds it takes you to ask another human being a question and receive a solid, well-informed answer usually trumps the hours you'd spend reaching the "same" conclusion. With less certainty. Oh, and you actually missed the trap everybody else already knows about, so you actually figured it out wrong.
The extent of the dichotomy is clearly not limited to these examples. It's easy to think of times you've had to pepper somebody with questions as well as times you wanted to hole up in a cave to get some code done. For my systems programming experience I'd hazard a guess that it's around an 80/20 split between concentration and collaboration.
So, it's interesting to ponder: if you were building a team, how would you structure the work space or work activities to enable collaboration when it was necessary, but enable concentration in the common case?
I suppose it's doubly difficult because you also want your team to feel empowered — capable of seeking out collaborative help when they need it in order to get things done and make progress, but also empowered to cordon themselves off and have at it.
I can pretty easily find research that involves hospital workers in the early 1990s, but I have to imagine that a team of brilliant systems programmers is a different beast altogether.
As a guy who writes code, there are a few basic things I ask before I jump into any project:
Will I learn?
Do the people rock?
Will it ship?
Does it matter?
I guarantee that you'll learn from working on SpiderMonkey. It's an important language implementation created by some of the most brilliant and approachable coders I've ever had the privilege of working with.
We ship like clockwork. When a patch gets submitted to trunk, it's in the Firefox release 18 weeks later.
Hack: this technology could fall into the right hands [image]
And when it comes to finding meaning in your work, Mozilla makes life easy.
In my opinion, the Mozilla mission is technological utopianism at its finest. If you believe in using your technological superpowers to help people, Mozilla is for you.
If you know how to write and debug C++ code, you have the skills to hack SpiderMonkey. We don't go crazy with the C++, so C coders should also feel pretty confident. The only tools required are the ones necessary to build Firefox.
SpiderMonkey is a language implementation, but don't let that get to you. Once you get your hands dirty (say, by fixing a few minor bugs) you'll realize that language VMs are no different from the other systems-level programs that you know and love.
The JS team tries to tag good first bugs. If you see a good first bug that interests you, feel free to go in and make a comment stating your interest.
If you'd like to ease into development a little more, you can check out the latest ECMAScript specification and use that to create tests for our test suite. This is a great way to ensure SpiderMonkey engine quality and cross-browser compatibility.
In typical open-source style, once you've found something that interests you, hack away!
And feel free to sample from the buffet: every bug that you work on teaches you about a different aspect of the engine.
You may also stumble onto a part of the engine that you'd like to specialize in — we loving having domain experts hacking on our code as well!
When you improve the engine, you can get your name added to about:credits, in a product that ships to something like half a billion users, which I think is pretty cool.
Lots of great details and walkthroughs are available on the "New to SpiderMonkey" wiki page.
Barrel (#coding, #jsapi)
Friendly people hang around in these IRC channels at irc.mozilla.org. #coding is for general questions, whereas #jsapi is for JS engine internals discussion. You can easily install ChatZilla as a Firefox add-on to get on IRC.
If you've had bad experiences with IRC in the past, fear not!@ I know, from personal experience, that the IRC moderators in these channels have a zero-tolerance policy for disrespectful behavior. We love (and are) our community.
On my back
I haven't provided any kind of engine internals overview, but I think this may be just enough information to get you intrepid hackers going.
I may find time to do more screencasts in the future, but don't wait on me. (I'm new to this whole medium and prefer to write code. ;-) In the meantime, there's a screencast intro on hacking the SpiderMonkey shell available on my blog.
The beauty of software, especially open source, is that you can mess around without taking any risks and by satisfying very few dependencies (i.e. a computer and the ability to install open source software).
Like the slogan says, with you hacking on Mozilla, the technology may have feallen into the right hands.
So, I hope that you'll consider hacking with us!
Please excuse my use of the colloqualism, "as a guy who writes code." On a second listen I realize it may be poorly placed, because I'm using my own criteria as an example of an arbitrary person who might be considering contributing to the Mozilla project — no gender implication for contributors was at all intended!
More fortunately, this note is a great opportunity for me to plug WoMoz, Mozilla's project to promote women's involvement in open source and encourage contributions. You can find members on #womoz on irc.mozilla.org.
Thoughts on the idea of "slidecasts"
Just to get this established up front: I'm super rusty at presenting any kind of material. Also, I've never tried to record a presentation on the same computer that I was reading notes off of. (Case in point: you can hear the clicking of a keypress when I change slides.)
Despite all this hedging, I'm not sure about slidecasts as a medium. I sometimes fumble when I ad-lib, so I effectively had to write out a whole script for these slides. That's why it sounds like I'm reading off of a piece of paper.
Screencasts (as opposed to slidecasts) are different because you're walking through a sequence of on-screen editing actions that are inherently difficult to put into words. It's also a lot of fun to see how somebody else uses their development environment.
Slidecasts harness the poignant messaging of slides, but lose the body language of recorded audience presentations, which is clearly an important component. Turning the slidecast script into words would have been simple, and potentially more accessible to people who don't have the time to watch video content at all.
...or maybe it's humanizing? I'm not sure. Perhaps I have to add more soaring rhetoric and fancy slides to make spoken word worthwhile.
I'm a little bit behind in my movie watching. About 35 years behind.
Yesterday I saw the movie "Network" (1976) for the first time. Humorous, cynical, and meta is totally my hook, so I had a ball with this one. However, it reminded me of a pretty solemn pattern that I wanted to write about.
I call this pattern the "new shiny", in the same sense that a house cat only sits in your lap in the absence of a shiny thing dangling just out of its reach. In the movie, an older man leaves his wife, with whom he previously shared a 25-year committed relationship, for a younger woman, with whom he's become infatuated.
Now, in this movie's allegory, that younger woman is a metaphor for television and stuff, but that's besides the point for this discussion.
The story presents an instance of the "new shiny" pattern. You happen upon a new opportunity, incompatible with an opportunity you're currently pursuing, and you're tacitly forced to make a choice: pursue the new opportunity, or, through inaction, continue with pursuit of the current opportunity.
As the movie points out, it's easy to become infatuated, even obsessed, with the new shiny, if only because striking out on a new path is exciting and optimistically promising in its "honeymoon phase". In this light, the situation becomes even more difficult: passivity results in an outright denial of something intriguing, leaving you wondering, classically, "what could have been".
Inevitably, evaluating the new shiny with sound reasoning and peace of mind becomes very difficult. The irrationality of attachment — whether to existing things or to things that might be — blurs rational evaluation, if there was really any to be had to begin with. Often, no matter which you choose, you will quickly begin to wonder how much better things would have been on the other path.
...lovers, technologies, jobs, subjects of interest, projects...
Some categories don't have the same existential scarcity that makes the new shiny perilous. Take food: there's little cost to returning after venturing off to sample another cuisine. You don't feel the same kind of remorse choosing soup over salad. Other categories are far less forgiving.
There's also ample reason to fear the new shiny. Every time you make a commitment you disavow the temptation of the new shiny and its hold over you. And, typically, unless you take steps to strategically isolate yourself, you have little control over new shiny encounters — these things are just stumbled upon in the course of everyday life.
There are very few tools at our disposal to deal with the new shiny properly. Human prescience is quite limited to begin with. I suppose that the new shiny is just the classic problem of man versus raw choice taken to its passionate, emotionally-involved and foresight-crippled extreme.