Seven Lessons I Learned at Mozilla by David Walsh

Offers readers "Habrahabr" translation showed me an interesting article "7 Lessons I've Learned at Mozilla» from the blog of David Welch (David Walsh).

Do you know what is a sign of good work? You will learn enough. And fast. And the best thing is that your employer and colleagues will encourage and promote your good work. This happens to me in my (almost) three-year job at Mozilla . This company continues to bring the best to me and encourages me to do more and better. Below are seven of the dozens of lessons I learned while working at Mozilla.

Send. Send. Send


I had never heard of “continuous deployment” until I got settled in Mozilla. I always worked on projects during sprints, and then provided a Git - tagged release with functionality developed during the sprint. The problem manifested itself in the fact that errors from the previous tagged release were transferred to the next tagged release and, thus, a few weeks later the bug was sent to production without a fix, despite the fact that it was fixed in the trunk -light almost immediately after detection. Sending code to productionseveral times during the day it contributes to a sense of fluidity / continuity of the process and allows you to correct errors INSTANTLY, and not at specified intervals. Continuous deployment also convinces developers not to delay sending code to the repository until they are convinced that the functionality is 100% complete. Quite often, 90% availability is good enough for a first run.

To admit defeat is NORMAL


“Admitting defeat” is a bit unpleasant, but Mozilla taught me that it is NORMAL to say “Do you know what? It won’t work ”or“ We can do better ”and then start over. Starting all over is a heartbreaking process, but the developers are not perfect, we cannot foresee all the possible problems. Starting over is better than stringing solutions that will always have flaws. I saw many projects and tasks in Mozilla that were restarted / redone and released much improved. Starting an authorization system ( Persona ) using a Firefox accounthas been delayed, the release of Firefox for iOS has been delayed, etc. In the end, it’s important to have a solid, reliable product / application, not a ball of duct tape. To remove this tape from the final product is CORRECT.

Being a Beginner is NORMAL


The last thing you want to be branded when you get a new job is “noob.” Since Mozilla is one step away from 99% of online stores, there is a very good chance that you will feel like a “noob” for some period of time. In Mozilla, I realized that being a “noob” is NORMAL. Why? Because everyone wants to help you become a beginner and then an expert, because everything is aimed at making this happen. I believe this situation can be in most organizations If you ever feel stupid or humiliated due to lack of knowledge, keep in mind that you are in the wrong place. It is NORMAL to be a “noob” for at least a short time.

Writing "Basic" code for large sites is still a challenge and an important task


I was told that I would play down my achievements at Mozilla. What I consider to be standard is actually not as simple as it seems to me. When I express my opinion that I have not done anything significant enough at Mozilla, people indicate that I have finished redesign MDN . I always thought that "a developer with 2-3 years of experience could do this." What I do not take into account is the responsibility: I messed up, and millions of other developers around the world would see these errors. Thus, despite the fact that the AJAX ad has left MDN, the fact that I have not ruined anything important is an achievement in itself.

Leaving work on time is NORMAL


In the past, I was branded as a workaholic. At a time when I timidly struggled with this stigma, this was probably true. After all, I got to where I am today, but for this I worked with an independently issued overtime mandate at every place I had ever been. In March 2013, when my son was born, I began to need to be able to leave work a little “earlier”, but at the same time, guilt should not have torn me apart. I still worked 40 hours a week, but I could not struggle with the desire to spend more time in the company, especially in such a global organization as Mozilla, with employees working at any time. With the help of my manager, I realized that it was NORMAL to judge my achievements every day, and not about the hours spent at work.

Localization is important


Having worked with the Dojo Toolkit in the past, I realized that localization always matters, but moving to Mozilla has opened my eyes that localization is vital. Not only does Mozilla have employees in every country, but there are also volunteers and users in most countries, so if you skip the localization of messages in code, you will find out pretty quickly.

People use bugtrackers in different ways.


Any Mozillian who worked with me will giggle at this place. I always perceived bugtrackers as some “we are going to do this” lists, but others use bugtrackers as a wall for ideas, encouraging messages, and messages for asking for preferences. I learned not to accept the error list as good news, and instead focused on the prioritized lists provided by project managers. It was really very difficult for me to accept this fact, but after almost 3 years I came to terms with it.

Also popular now: