Seven Lessons I Learned from Mozilla by David Walsh
I offer the readers of Habrakhabr a translation of the interesting article “7 Lessons I've Learned at Mozilla” from David Walsh’s blog.
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 work at Mozilla . This company continues to bring the best in me and pushes me to do more and better. Below are seven of the dozens of lessons that I learned while working in Mozilla.
I have never heard of "continuous deployment" until I got settled in Mozilla. I always worked on projects during the sprints, and then provided a git - tagged release with the functionality developed during the sprint. The problem was that the 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 branch almost immediately after detection. Sending code to production several times throughout the day contributes to the feeling of fluidity / continuity of the process and allows you to correct errors MUSTELY, and not at specified intervals. Continuous deployment also convinces developers not to delay sending code to the repository until they believe that the functionality is 100% complete. Quite often, 90% readiness is good enough for a first run.
“To admit defeat” is a bit unpleasant, but Mozilla taught me that it is OK to say, “You know what? This will not work ”or“ We can do better ”, and then start over. Starting all over again is a heartbreaking process, but the developers are not perfect, we cannot foresee all possible problems. Starting over is better than stringing solutions that will always have flaws. I have seen many projects and tasks in Mozilla that have been restarted / redesigned and released into the world much improved. The launch of the authorization system ( Persona ) using the Firefox account has been postponed, the release of the Firefox browser for iOS has been delayed, etc. In the end, it is important to have a solid, reliable product / application, and not a ball of duct tape. To remove this tape from the final product is CORRECT.
')
The last thing you want to be branded for 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 “noob” for a certain 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 designed to make this happen. I suppose 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 OK to be a noob, at least for a short time.
I was told that I was diminishing my achievements in Mozilla. What I consider standard is actually not as simple as it seems to me. When I express my opinion that I have not done anything substantial enough in Mozilla, people indicate that I have completed the MDN redesign . I always thought that "a developer with 2-3 years of experience could do it." What I do not take into account is the responsibility: I messed it up, and millions of other developers around the world would see these errors. Thus, despite the fact that AJAX -ad has left MDN, the fact that I have not spoiled anything important is an achievement in itself.
In the past, I was branded as a workaholic. At a time when I was timidly struggling with this stigma, it probably was 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 ever was. 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 the feeling of guilt should not have torn me apart. I still worked 40 hours a week, but I couldn’t struggle with the desire to spend more time in the company, especially in a global organization like Mozilla, with employees working at any time. With the help of my manager, I realized that it was OK to judge my achievements every day, and not about the hours spent at work. In the end, fixing a high priority error in 15 minutes is more important than spending the whole day on 10 low priority errors.
Having worked with the Dojo Toolkit in the past, I realized that localization always matters, but the transition to Mozilla opened my eyes, that localization is vital. Not only do Mozilla have employees in every country, but there are also volunteers and users in most countries, so if you miss the localization of the message in the code, you will find out pretty quickly.
Any Mozillian who worked with me will giggle at this place. I have always perceived bugtrackers as “we-going-it-do” 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 a gospel and instead focused on the prioritized lists provided by the project managers. It was really very difficult for me to accept this fact, but after almost 3 years I came to terms with it.
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 work at Mozilla . This company continues to bring the best in me and pushes me to do more and better. Below are seven of the dozens of lessons that I learned while working in Mozilla.
Send it. Send it. Send it
I have never heard of "continuous deployment" until I got settled in Mozilla. I always worked on projects during the sprints, and then provided a git - tagged release with the functionality developed during the sprint. The problem was that the 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 branch almost immediately after detection. Sending code to production several times throughout the day contributes to the feeling of fluidity / continuity of the process and allows you to correct errors MUSTELY, and not at specified intervals. Continuous deployment also convinces developers not to delay sending code to the repository until they believe that the functionality is 100% complete. Quite often, 90% readiness is good enough for a first run.
To admit defeat is NORMAL
“To admit defeat” is a bit unpleasant, but Mozilla taught me that it is OK to say, “You know what? This will not work ”or“ We can do better ”, and then start over. Starting all over again is a heartbreaking process, but the developers are not perfect, we cannot foresee all possible problems. Starting over is better than stringing solutions that will always have flaws. I have seen many projects and tasks in Mozilla that have been restarted / redesigned and released into the world much improved. The launch of the authorization system ( Persona ) using the Firefox account has been postponed, the release of the Firefox browser for iOS has been delayed, etc. In the end, it is important to have a solid, reliable product / application, and not a ball of duct tape. To remove this tape from the final product is CORRECT.
')
Being a Newbie is NORMAL
The last thing you want to be branded for 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 “noob” for a certain 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 designed to make this happen. I suppose 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 OK to be a noob, at least for a short time.
Writing "Basic" code for large sites is still a challenge and an important task.
I was told that I was diminishing my achievements in Mozilla. What I consider standard is actually not as simple as it seems to me. When I express my opinion that I have not done anything substantial enough in Mozilla, people indicate that I have completed the MDN redesign . I always thought that "a developer with 2-3 years of experience could do it." What I do not take into account is the responsibility: I messed it up, and millions of other developers around the world would see these errors. Thus, despite the fact that AJAX -ad has left MDN, the fact that I have not spoiled anything important is an achievement in itself.
Leaving work on time is OK
In the past, I was branded as a workaholic. At a time when I was timidly struggling with this stigma, it probably was 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 ever was. 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 the feeling of guilt should not have torn me apart. I still worked 40 hours a week, but I couldn’t struggle with the desire to spend more time in the company, especially in a global organization like Mozilla, with employees working at any time. With the help of my manager, I realized that it was OK to judge my achievements every day, and not about the hours spent at work. In the end, fixing a high priority error in 15 minutes is more important than spending the whole day on 10 low priority errors.
Localization is important
Having worked with the Dojo Toolkit in the past, I realized that localization always matters, but the transition to Mozilla opened my eyes, that localization is vital. Not only do Mozilla have employees in every country, but there are also volunteers and users in most countries, so if you miss the localization of the message in the code, you will find out pretty quickly.
People use bug trackers in different ways.
Any Mozillian who worked with me will giggle at this place. I have always perceived bugtrackers as “we-going-it-do” 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 a gospel and instead focused on the prioritized lists provided by the project managers. It was really very difficult for me to accept this fact, but after almost 3 years I came to terms with it.
Source: https://habr.com/ru/post/250305/
All Articles