Besides 3 months interrupted to finish degree requirements, and including an internship, I’ve been at Mozilla for about 8 months now. After reading a blog post of another software engineer’s experience at Microsoft, I count my blessings. Reading that article set off too many alarms in my head. It was well written, and I sugguest you go read it, but my takeaway was that that any big name corporation people dream about working at is actually quite dystopian, and I do not feel that that is the case here.
Expect no documentation in corporations
Expect documentation to be sparse or bit rotted
When developers are coding at an unhindered pace, writing documentation does suck. But once a project reaches a certain size, it cannot sustain growth without additional support from additional developers. When a project reaches this point, it’s worthwhile to step back from unbridled coding to write some docs for your new devs. This is really important for open source projects, to get help from volunteers. I’ve heard roughly 50% of Mozilla’s code comes from volunteers; so making their lives easier is a must. Also, writing documentation is a great way to start contributing to an open source code base. Documentation is a gift that keeps on giving. By keeping information to yourself, you have power over others, but that doesn’t help your organization move forward as a whole. Depending on the pace of code development, documentation tends to bit rot. I’m all for code that’s clear enough to be self documenting, but sometimes comment blocks that describe high level overviews of the code base’s architecture can really help newbies. When you update code, you should update the relevant tests and documentation.
It is not what you do, it is what you sell
It’s all about maintainability
I’ve had nightmare code reviews. Literally reviews so long I’ve had to print them out and cross them out one by one as I fixed them to help me keep track of what I had left to fix. But by working through them, I learned an awful lot about professional code development. It literally taught me to write some bulletproof code. While it was embarrassing for me at the time, and even a little now to admit, I’m glad because it helped me grow professionally at an accelerated pace and I can appreciate that. People come and go, but their code lives on. Think about this, some day you will die, but code you’ve written will probably outlast you. You wont be around to defend your coding decisions, so commit it right while you can. Imagine the poor bastard who has to maintain your code, why not try and make their life a little easier? As an engineer, ethics and morality are the Hippocratic Oath you answer to, not someone with a business title. If you think this is wrong, if you’re not allowed to offer feedback or criticize the decisions made by those above you, then you work for the wrong company.
Not everbody is passionate for engineering
Everyone here is super passionate about what they do
While a lot of people here have active family lives, they are all active Mozillians. I’ve yet to meet anyone who didn’t have a common ground in web based software (back end, front end, browser, OS, graphics, etc.) to speak the same language as me, but also acute knowledge in his or her specialty. By being surrounded be so many smart, enthusiastic people I can tell you all about JavaScript performance, about compiler front ends and back ends, about codecs, about layout and rendering, about handling billions of hits a day, etc. If you’re the smartest in the group, the group is dragging you down. I frequently feel like I’m not the smartest when surrounded by most of my peers, and I’m cool with that. I am young and naïve and have so much to learn, and Mozilla is an awesome place to grow.
2-3 hours of coding a day is great
Contribute at your pace
There’s no pressure here about time spent coding. Time spent or number of lines written is not a benchmark to live by, code quality is. I’m a five o’clock developer, but when I go home I’m reading up on various software topics and expanding my range of knowledge. I have a big bookshelf I pride myself in filling with various programming and hardware design related books. Mozilla provides all kinds of distractions (tech talks, food, pool table, video games), because comfortable developers are better developers. I went to a talk today where the senior employee talking told me that we should not waste our time in meetings if we feel they are meaningless. “Just walk out!”
Not giving back to the public domain is the norm
Giving back to the public domain is the norm
My very first week as an intern, I had just finished my first project. I approached my manager and said “Hey I’m going to publish this now on Github. That’s cool right?” There was an uncomfortably long pause from my manager, then “yeah man go for!” Literally everything I’ve ever worked on here has been published as open source. Writing software is about expression. To be able to publish my code freely, literally the reason the World Wide Web was created, allows me to be a part of someone else’s professional development; my expressions and code mannerisms living on in theirs. Probably the coolest story I have about working here on open source software happened a few weeks ago. It was a Friday afternoon and I was assessing issues in our issue tracker, deciding which I was going to tackle first on Monday. Monday morning I came in to a pull request with my name on it. Literally some person who had never spoken to me, nor any other core devs. Someone who didn’t live in the same country as me or possibly speak my language natively, they just picked up an issue and wrote a patch in a mutually common language: code. It didn’t matter that the volunteer was or wasn’t employed by Mozilla; they understood the problem they faced enough to fix it for themselves and everyone else. Anyone can partake in the development process and earn the priviledge and trust to become a core volunteer.
The world outside is not known here a lot
Everyone here is aware of the outside world
Seeing as we tend to wind up on HN et al almost daily, many of us frequent HN, Reddit, Twitter, and /.. It’s always interesting to see coworkers show up in comment threads. When you say something hurtful about Mozilla or Mozilla products in these forums, more than a few people here are going to see this and get their feelings hurt. It’s really unfortunate especially since our issue tracker is public, and it takes a few minutes to fill out a simple bug (and a few more for steps to reproduce) where we actually look for issues (and not on Twitter, for instance). Anyways, being aware of the new hotness has benefits again in terms of expression. So much of Rust is based on ideas from various languages. So much of ECMAScript 6 comes from CoffeeScript. So many libraries have interesting and useful abstractions. Saying “bah humbug new hotness bullshit” is naïve; new languages and frameworks became popular because people found that they made software development marginally better, and by closing your mind to them you loose out on being able to take those ideas and incorporate them in your current or favorite language/framework/project. If anything, being more informed about your enemy makes your argument stronger. I can’t tell you how many times I’ve heard someone talk shit about Ruby, yet when pressed didn’t have the slightest knowledge of the language. Yet I’ve had truly great debates with those well versed in Ruby. Try to only remark on positives, and lay off negatives unless they have actually bitten you.
Copy-pasting code can be okay
Measure once, cut twice [is wrong!]
Stack overflow is great. There’s no way to know every little bit of C or C++. JavaScript has some bad parts. But by copying and pasting code that was written from another context, you’re probably introducing bugs into your code. Don’t repeat yourself, and don’t cut corners just to get shit done.
Code reviews can be skipped
Code reviews are nothing but beneficial
If they are taking too long to the point where you’re considering cutting them out, your team is probably understaffed and overworked. Code reviews allow others to spot bugs that you may have overlooked. Seeing as they didn’t write the code, they can look at the code objectively without the same assumptions you made that may or may not actually be there. It also allows you to grow as a developer, assuming you take the lessons learned to heart. The reviewer may learn a thing or two. This should obviously occur less frequently (otherwise you have the lesser experienced coder reviewing the more experienced coder’s code), but you can still teach an old dog new tricks. If you get to a point where you’re getting too bogged down in code reviews, you probably haven’t been delegating enough or haven’t communicated well enough with your manager or the rest of the team.
Latest software, meh
Latest software, duh
Old, unpatched versions of popular software are susceptible to security flaws. Java especially. It may involve work to update your code for new environments, but it’s easier to bite the bullet in small increments frequently than it is to wait until it’s too late.
Your specialties usually do not matter
You were hired because of the need for someone on your team to have a certain expertise
If this is not the case, what the hell is your recruiting department doing? You know the part where start-ups say speed is everything? It’s because of the big established players not optimally allocating resources. Even if you’re not happy when you get here, you’re able to move or at least work on something else. I’ve had the freedom to work on Rust compiler, something I never would have dreamed of doing before and not something I’m an expert in but something that is mentally fulfilling and thought provoking. Many of the people here are famous for one thing or another and many of them work on things similar to what they’re known for, while others are free to start new or tackle existing projects. We frequently borrow people from other teams who are able to lend a hand in various aspects they specialize in.
Besides these responses, there’s just so much about my job that I love. The Mozilla Manifesto is my holy book. It makes me so happy to be a part of such an incredible organization. We have the transparency and accountability the government could only dream of. Instead of running from wrongdoing, we fight! We have so many interesting projects that anyone can get involved with! We have so many employees well known for their contributions. We have so much competition that keeps us humble. We have so many experienced and friendly senior software engineers who make great mentors to the new guard. We have so many people dedicated to users, who don’t compromise privacy for security (as those who do deserve neither). We have such an amazing community of staff, volunteers, reps, advocates, evangelists, users, localizers, testers, etc. who understand that they have the power to affect the trajectory of their favorite open source browser, mobile operating system, service, or library.
Again, I’m not making any of these points with your experiences in mind. I’m talking about what’s the norm here at my place of employment.
I’ve been told that working at Mozilla out of college spoils you. If that’s the case, if life at M$ is the norm, then my next job will have to be one of my own creation. I can only hope that a company I [will] create be in the image of Mozilla. Even then, I’ll still be a Mozillian; once a Mozillian, always a Mozillian. When people complain about their jobs, it’s completely foreign to me. You always have the power to change your situation, and I view disagreement to that point as self-doubt. I love the work that I do and if your company does something that you don’t agree with, then I challenge you to change your situation. Be that speaking out or moving on.
At the end
It’s about expressing your legacy; that will have repercussions that will shape our world. Chasing paychecks and enduring crappy working conditions is not a way to live. So what do you think, world traveler?