[Из песочницы] Семь уроков, которые я получил в Mozilla, от David Walsh
Предлагаю читателям «Хабрахабра» перевод показавшейся мне интересной статьи »7 Lessons I«ve Learned at Mozilla» из блога Девида Уэлша (David Walsh).Вы знаете, что является признаком хорошей работы? Вы узнаете достаточно. И быстро. А лучшее — это то, что ваш работодатель и коллеги будут поощрять и содействовать вашей хорошей работе. Такое происходит со мной в моей (почти) трехгодичной работе в Mozilla. Эта компания продолжает привносить лучшее в меня и подталкивает делать больше и лучше. Ниже приведены семь из десятков уроков, которые я выучил, работая в Mozilla.
Отправляй. Отправляй. ОтправляйЯ никогда не слышал о «continuous deployment» (непрерывном развертывании), пока не устроился в Mozilla. Я всегда работал над проектами во время спринтов, а затем предоставлял Git-tagged релиз с функциональностью, разработанной в течении спринта. Проблема проявилась в том, что ошибки из предыдущего тегированного релиза переносились в следующий тегированный релиз и, таким образом, через несколько недель баг отправлялся в production без фикса, несмотря на то, что он был исправлен в trunk-ветке практически сразу после обнаружения. Отправка кода в production несколько раз в течении дня способствует ощущению текучести/непрерывности процесса и позволяет исправлять ошибки МНГНОВЕННО, а не через заданные промежутки времени. Непрерывное развертывание также убеждает разработчиков не откладывать отправку кода в репозиторий, пока они не уверуют в то, что функциональность завершена на 100%. Довольно часто 90% готовность — это достаточно хорошо для первого запуска.Признать свое поражение — это НОРМАЛЬНО «Признать поражение» немного неприятно, но Mozilla научила меня, что это НОРМАЛЬНО, чтобы сказать «Знаете, что? Это не будет работать» или «Мы можем сделать лучше», а затем начать все сначала. Начать все сначала — это душераздирающий процесс, но разработчики не совершенны, мы не можем предвидеть все возможные проблемы. Начать сначала — это лучше, чем нанизывать решения, которые всегда будут иметь недостатки. Я видел много проектов и задач в Mozilla, которые были перезапущены/переделаны и выпускались в свет намного улучшенными. Запуск системы авторизации (Persona) с использование учетной записи Firefox был отложен, выпуск браузера Firefox для iOS был задержан, и т.д. В конце концов, это важно — иметь цельный, надежный продукт/приложение, а не шар из клейкой ленты. Убрать эту ленту из конечного продукта — это ПРАВИЛЬНО.Быть Новичком — это НОРМАЛЬНО Последнее, чем вы хотите быть заклеймены, когда получите новую работу — это «нуб». Поскольку Mozilla в одном шаге от 99% интернет-магазинов, есть очень хороший шанс, что вы будете чувствовать себя «нубом» в течение некоторого периода времени. В Mozilla я понял, что быть «нубом» — это НОРМАЛЬНО. Почему? Потому что каждый хочет помочь вам стать начинающим, а затем экспертом, потому что все направлено на то, чтобы это произошло. Я полагаю, такой расклад может быть в большинстве организаций. Если когда-нибудь вы почувствуете себя глупым или униженным из-за недостаточных знаний, имейте в виду — вы находитесь в неправильном месте. Это НОРМАЛЬНО, быть «нубом», по крайней мере в течение короткого времени.Написание «Basic» кода для больших сайтов все еще является вызовом и важной задачей Мне сказали, что я приуменьшаю мои достижения в Mozilla. То, что я считаю стандартным, на самом деле не так просто, как мне это кажется. Когда я высказываю свое мнение, что не сделал ничего достаточно существенного в Mozilla, люди указывают на то, что я закончил redesign MDN. Я всегда считал, что «разработчик с 2–3 годами опыта мог бы сделать это». То, что я не принимаю во внимание, так это ответственность: напутай я, и миллионы других разработчиков по всему миру увидели бы эти ошибки. Таким образом, несмотря на то, что AJAX-ад ушел из MDN, тот факт, что я не испортил что либо важное — уже достижение само по себе.Уйти с работы вовремя — это НОРМАЛЬНО В прошлом я был заклеймен как трудоголик. В то время, когда я робко боролся с этим клеймом, это, вероятно было правдой. После всего я попал туда, где нахожусь сегодня, но для этого я работал с самостоятельно выданным мандатом на сверхурочную работу на каждом месте, где когда-либо был. В марте 2013 года, когда родился сын, я начал нуждаться в том, чтобы иметь возможность уйти с работы немного «раньше», но при этом чувство вины не должно было раздирать меня. Я все еще работал 40 часов в неделю, но не мог бороться с желанием находиться больше времени в компании, особенно в такой глобальной организации как Mozilla, с сотрудниками, работающими в любое время. С помощью моего менеджера я понял, что это НОРМАЛЬНО, чтобы каждый день судить о своих достижениях, а не о проведенных на работе часах. В конце концов исправить ошибку с высоким приоритетом за 15 минут более важно, чем потратить весь день на 10 ошибок с низким приоритетом.Локализация важна Поработав с Dojo Toolkit в прошлом, я понял, что локализация всегда имеет значение, но переход в Mozilla открыл мне глаза, что локализация жизненно необходима. Мало того, что у Mozilla есть сотрудники в каждой стране, но также есть добровольные помощники и пользователи в большинстве стран, поэтому, если вы пропустите локализацию сообщения в коде, вы это довольно быстро узнаете.Люди используют багтрекеры по-разному Любой Mozillian, который работал со мной, будет хихикать в этом месте. Я всегда воспринимал багтрекеры как некие «мы-собираемся-это-сделать»-списки, но другие используют багтрекеры как стену для идей, обнадеживающих сообщений, и сообщений для выпрашивания преференций. Я научился не принимать список ошибок как благую весть и вместо этого сосредотачивался на приоритезированных списках, предоставленных руководителями проектов. Это было действительно очень трудно для меня — принять этот факт, но спустя почти 3 года я с этим смирился.
