My experiences working local and remote for Mozilla

I started working for Mozilla in the beginning of June 2011. In my near three months at Mozilla, I’ve worked mostly full-time from the Mozilla headquarters in Mountain View, CA. I’ve also spent two weeks working from East Lansing, MI and another day working from our San Francisco office.

Mozilla has employees and contributors located all around the world. Catering to all timezones can be hard to do successfully, but I have been impressed with the amount of thought and resources that are applied to include/accommodate those working from different regions.

Once a week there is a weekly project status meeting that is broadcasted on Air Mozilla. Some meetings are also archived for those who happen to be in bed at 11am PDT. We also have other regularly scheduled meetings that take place in some of our conference rooms.

One such conference room is Warp Core. Meetings that are held in the (physical) Warp Core room can often be visited through our Vidyo conference system in a virtual Warp Core room. The virtual room and physical room don’t always overlap, but in most situations they do. The big power of this is the ability for remote employees to feel free to join meetings without being invited. I’ve worked at companies before whose remote-working setup required someone local to phone the remote employees. This often led to remote employees being left out of daily stand-ups and other meetings.

All large conference rooms at Mozilla include a high quality video camera that points at most of the room. When remote employees connect through video conferencing, their video shows up on a TV in the conference room. This allows all participants the opportunity to see each other. Meeting attendees also have the option to phone in.

Code reviews take place asynchronously through BugZilla, and most discussions take place either through email or on IRC. I use IRCCloud.com to keep a persistent IRC connection open in case someone wants to contact me when I am away from the computer.

Overall, I think Mozilla does a great job at helping their remote employees be as successful as possible.

Michigan Agile and Beyond 2011

A couple days ago, I registered for the Michigan Agile and Beyond 2011 conference. A crew of TechSmith employees headed down to Dearborn, MI last year for the inaugural event. This will mark the second year of the conference and will feature speakers from across the region that work for companies of all sizes.

Personally, I’m looking forward to learning more about Kanban. The software team that I work on has adopted Kanban recently and we’re still learning how to use to its maximum potential.

The conference takes place on Saturday, March 12 and is only $79 to register during the month of January.

StackOverflow DevDays Toronto Recap/Review

It seems a little late to write my review of the StackOverflow DevDays conference I attended in Toronto on October 23rd, but I had said that I was going to put it up here. This is me backing up my word.

The conference had six talks, including the opening keynote. Of the six talks, I felt three could have been left out. The whole conference took place in one large theater, meaning there was no choice of talk to attend. Given that, the language/framework overviews of ASP.net/MVC, Python, and jQuery all were pretty boring. I’ve used all three of them before, and all the talks felt redundant (to me). I think that had it been a conference where you could choose which session to attend, then these talks could have had a lot more value.

The three notable talks were those given by Joel Spolsky (co-founder of StackOveflow), Greg Wilson (Associate Professor in Computer Science at University of Toronto), and Reginald Braithwaite (Software Developer and Development Manager).

Joel Spolsky‘s Opening Keynote

Joel Spolsky’s keynote was all about writing software with less features and simplicity. He mentioned a study where researchers had customers of a grocery store sample either 6 different flavors of jam or 24 different flavors. When 6 flavors were offered, 40% stopped and tried some. When 24 flavors were offered, 60% stopped and sampled. Yet the interesting twist comes from who purchased. The 6-different group had 30% of the stores customers (not just the ones who sampled) purchase, while the 24-different group only had 3% purchase. He draws the conclusion that too many choices just complicates things and people get intimidated. (I’d like to get access to this research. If anybody knows the publication, please let me know in the comments Update: I just got a link to it: When Choice Is Demotivating).

The main point of the talk is that we should have less features and less choices. Joel mentioned that:

Too often we developers ask users to make decisions that they shouldn’t need to. We tell them, “don’t hit the back button”, “how many items should show up in a recently used list?”, “continuing will cancel your appointments. should i cancel your appointments? [ok] [cancel]”.

Users do not want a dialog with their software, they just want to get stuff done. They don’t want to be interrupted while giving a presentation, or when there is a time crunch and the software pops up to tell them that an update is available.

One of the scenarios he brought up when explaining the need for less dialogs is of a CFO and her secretary. The CFO was cheating on her husband with her secretary and one day out of the blue her husband walks in to the office. The CFO panics and her secretary turns to face her. He says pay me now or I tell your husband. She obliges and opens up QuickBooks (with only a minute to spare before her husband walks in) and then QuickBooks tells her that she has an update pending. That update dialog is the last thing she wanted to see.

Greg Wilson – Professor at University of Toronto

This was an awesome talk. Most of the talk centered around how people within the computer science field are too willing to take data and new methodologies at face value without digging in and calling people’s bluff. He also jumped around and brought up the lack of women in Computer Science and code quality as it pertains to a company’s organizational chart.

When talking about taking new methodologies at face value, he says that none of the facts that argue for Agile have been proved and those following Agile are just the blind leading the blind. For an example, he cited the quote “The best programmers are 28 times more productive than the worst.” The study that originated that quote is heavily cited, yet looking deeper in to the study, it can be seen that we shouldn’t take at face value all these statistics. It turns out that the study was conducted by observing 12 programmers for one afternoon. Even then, what does it mean to be more productive?

He also talked about the need for more women in computing, and the Dweck Effect that is happening. He recommended reading the book, “Why Aren’t More Women In Science?“. (I’ve added it to my want-to-read list).

We as developers need to be humble. This does not mean bowing down to our bosses. It means if we are screwing up, admit it, fix it, and move on. We are not the best developers in the world, we do write crap code, and we need to be honest. He also brings up that code reflects the organizational chart of the company. If two people have different managers, they will be pulled in different directions and the code will show.

Reginald Braithwaite – Software Developer and Development Manager

Reginald Braithwaite was introduced by Joel Spolsky as one of the smartest people that Joel knows. Reg is known from rewriting Ruby to include Lazy Evaluation and Extension Methods. Very little of the talk focused on Ruby, and more about how we are “thinking about thinking about programming“.

He says that you should organize your code as though you are creating a presentation or writing an essay. If there is a large amount of code that does not matter, you should look at abstracting it out or fixing it.

Throughout the talk, he continued to drive in the point that we should think about thinking about programming. We will run in to a problem that appears hard to solve. There is a way that it can be made easier, and we might need to take a step back. “A programming language is just a notation of thought. A programming language can tell somebody how the developers who use that language think.” We should be saying, “What is the way that I should be thinking about solving this problem?”

To give an analogy, he brought up a Winston Churchill quote where he said that he was at a bar and a young lady came up to him and called him a drunkard. In reply he said, “Yes, and you are ugly. But in the morning I will be sober.” The point of that quote is that, “if there is a limitation, don’t accept it as an ugly problem, make it a drunk problem.” No problem is impossible, you may just be thinking about solving the problem wrong, and you should be thinking about how you are thinking about solving the problem.

In closing, he gave an Alan Perlis quote: “A language that doesn’t affect the way you think about programming, is not worth knowing.”

Those three talks were well worth the trip from Okemos, MI to Toronto, Ontario. I’m looking forward to next year’s StackOverflow DevDays. Will I see you there?