7 Lessons I’ve Learned at Mozilla

You know what the sign of a good job is?  You learn. A lot.  And quickly.  And best of all -- your employer and colleagues encourage and foster it.  Such has been the case in my (almost) three years at Mozilla.  Mozilla continues to bring out the best in me and push me to do more and do better.  The following are seven of the dozens of lessons I've learned at Mozilla.

Ship.  Ship.  Ship.

I had never heard of "continuous deployment" until I got to Mozilla -- I had always worked on projects for sprints and then provided a git-tagged release of the given sprint's improvements.  The problem became that bugs in the previous tag were added to the next tag, and thus a few weeks would go by without the bug being fixed on production, though the bug had been fixed in trunk shortly after its report.  Pushing to production several times a day promotes the feeling of fluidity and allows you to fix bugs NOW instead of at set intervals.  Continuous deployment also ensures developers don't wait until they believe a feature is 100% complete before pushing -- many times 90% is good enough for a first run!

It's OK to Admit Defeat

"Admit defeat" is a bit harsh but Mozilla taught me it was OK to say "You know what?  This wont work" or "We can do better" and then start over.  Starting over is a heart-breaking process but developers aren't perfect, we cannot foresee every possible problem, and starting over is better than stringing along a solution that will always have holes.  I've seen many projects and tasks at Mozilla be restarted and come out exponentially better.  Persona was abandoned for Firefox Accounts, the original Firefox app for iOS was pulled, etc.  In the end, it's important to have a solid product and not a ball of duct tape, and throwing away the tape for the end product is OK.

It's OK to Be the Noob

The last thing you want to be branded when you get to a new job is a "noob," and since Mozilla is a step up from 99% of web shops out there, there's a very good chance you'll come in at least feeling like the noob for some amount of time.  What I've found at Mozilla is that it's OK to be a the noob.  Why?  Because everyone wants to help you become a novice, then an expert, because it all goes to help the overall cause.  I have to believe that's the case in most organizations.  If ever you are made to feel foolish or inferior for knowing less, you're in the wrong place.  It's OK to be a noob, at least for a short while.

Writing "Basic" Code on Large Sites is Still Challenging and Important

I'm told that I minimize my achievements at Mozilla; i.e. something I consider basic isn't as easy as I feel it is.  When I make the point that I've not done anything significant enough at Mozilla, people point out that I completed the redesign of MDN.  I always counter with "a 2-3 year developer could have done that."  What I don't take into account is the responsibility:  mess up and millions of other developers around the world would have seen those mistakes.  So despite not having AJAX'd the hell out of MDN, the fact that I didn't brick anything major was an achievement in itself.

It's OK to Leave Work

I've been branded a workaholic in the past and while I sheepishly fight the label, it's probably true.  After all I got to where I am today but working self-mandated overtime at every job I've ever had.  When my son was born in March 2013, I started to need to leave work a bit "early" and the guilt of doing so was eating me alive.  I was still doing my 40 hours but I couldn't come to grips with not being there all the time, especially at a global organization with employees working at all hours.  With the help of my manager I realized that it's OK to judge each day on its accomplishments instead of a clock;  after all, fixing a severe priority bug in 15 minutes is more important that 10 low priority bugs in a day.

Localization Matters

Having worked with Dojo Toolkit in the past, I knew that localization was always a factor but moving to Mozilla was a massive wakeup call that localization was essential.  Not only does Mozilla have employees in every country but also has contributors and users in even more countries, so if you miss a localized message in code, you'll know it out quickly.

People Use Bug Trackers Differently

Any Mozillian that's worked with me will giggle at this one.  I've always known bug trackers as definitive "WE ARE GOING TO DO THIS" lists, but others use bug trackers as idea walls, hopeful suggestion posts, and personal preference moaning posts.  I've learned to not take bug lists as gospel and instead focus on prioritized lists provided by project managers.  This has been a really, really difficult change for me but almost 3 years later I've come to grips with this fact.