Сім уроків, які я отримав в 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 роки я з цим змирився.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.