Предлагаю читателям «Хабрахабра» перевод показавшейся мне интересной статьи «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 года я с этим смирился.
Автор: ipetrov
