Автор оригинала: Monica Lent

Оригинальный перевод

Скоро наступит десятый год, как я профессионально занимаюсь программированием. Десять лет! И кроме формальной работы, почти две трети своей жизни я что-то создавала в интернете. С трудом вспоминаю годы, когда я не знала HTML: даже странно, если подумать об этом. Некоторые дети учатся музыке или балету, а я вместо этого создавала волшебные миры, кодируя в своей детской.

Размышляя об этом первом десятилетии регулярного получения денег за ввод странных символов в терминал, хотелось бы поделиться некоторыми наблюдениями, как изменилось моё мышление за годы работы.

Возможно, нынешние джуниоры найдут здесь кое-что из своих убеждений и посмотрят на них с другой стороны. Или осознают, что они уже избавились от этого, поэтому зашли гораздо дальше, чем я была на вашем этапе.

Нынешние сеньоры, возможно, захотят тоже поделиться забавными (и немного унизительными) историями о том, какие уроки извлекли из своего джуниорского опыта.

Для ясности подчеркну, что джуниоры потрясающие: просто появляться на работе, чтобы учиться новому, — это уже требует тонны мужества. Это статья о моём собственном опыте и обучении. Я вовсе не обобщаю, что все младшие разработчики так думают или ведут себя.

Надеюсь, пост вам понравится и напомнит что-то из прошлого или настоящего.

Спасибо Артёму и Саре за отзывы!

Абсолютные истины джуниора, от которых пришлось отучиваться

1. Я старший разработчик

Когда я впервые попыталась устроиться на работу, мне было 19 лет. Вакансия называлась «студент веб-мастер». Это довольно удивительное название работы, потому что вы считаетесь и «студентом», и «мастером» одновременно. В наши дни все хотят быть «инженерами», потому что это звучит более модно, но по мне «мастер» — более подходящее слово для этого ремесла. В любом случае, моя работа состояла в том, чтобы писать PHP и MySQL и поддерживать наш сайт на Drupal, а также создавать некоторые внутренние инструменты.

Поскольку перед этим я несколько лет кодировала в своей спальне, то была уверена, что эти годы считаются за «годы опыта». Поэтому, когда меня спросили о том, сколько у меня опыта написания на PHP, я уверенно ответила: «3 или 4 года!»

Я думала, что много знаю о SQL, потому что умею делать outer join'ы (внешние объединения).

А когда я погуглила, то выяснила, что три-четыре года опыта означают большую кучу денег.

Перейдём к моей последней работе, которую я получила после пяти лет «комбинированного» студенческого и профессионального опыта (который я считала обычным опытом). В то время мой код практически никогда не проходил код-ревью. Я запускала ssh на сервере и делала git pull. Уверена, что никогда не видела ни одного пулл-реквеста. Не поймите меня неправильно, на первых двух работах я узнала массу потрясающих вещей, просто никогда не работала с другими разработчиками в той же кодовой базе. И всё же я подала заявку на должность «старшего инженера фронтенда», получила предложение и приняла его.

Так я стала старшим разработчиком в зрелом возрасте 24 лет.

Ведь они не дали бы мне эту должность, если бы я действительно не была старшим разработчиком, верно?! Конечно, мой впечатляющий опыт привёл меня к этой вершине, так что люди должны меня слушать!!! Я на пике своей технической карьеры, при этом самая молодая в офисе.

Прямо как босс.

Что я в итоге поняла

Не весь опыт одинаков. Мой опыт кодирования в спальне, работа студентом-программистом отличается от научных исследований в информатике и работы в растущем стартапе. Это разный опыт. За год работы в техподдержке в начале своей карьеры вы можете узнать в десять раз больше, чем за пять лет в индивидуальных проектах (или с минимальной обратной связью). Если ваш код никогда не просматривают коллеги, обучение идёт намного медленнее.

Вот почему так важны наставники, а ваша команда гораздо важнее, чем разница в пару долларов в зарплате. Не соглашайтесь на должность джуниора, где вы будете работать в одиночку! И не выбирайте первую работу (или, честно говоря, любую работу) только на основе зарплаты. Команда — вот где настоящая ценность.

Я также узнала, что названия должностей ничего не означают сами по себе. Позиция CTO может быть в команде из 5 человек, 50 или 500 человек. Это совершенно разная работа, хотя название идентично. Так что мой титул «сеньора» вовсе не делал меня ведущим программистом. Кроме того, иерархические титулы по своей сути ущербны и их трудно сравнивать между собой. Я поняла, что важно не зацикливаться на названиях и не стоит использовать их в качестве какой-то внешней проверки.

2. Все пишут тесты

Первую половину карьеры я работала в исследовательской сфере. В частности, три с половиной года над одним проектом с государственным финансированием, а затем полтора года в университете на кафедре обработки естественного языка. Могу сказать одно: программирование в научной среде полностью отличается от программирования в коммерческой индустрии.

По большей части, вы не создаёте приложения. Вы работаете над алгоритмами или анализируете наборы данных. В качестве альтернативы, если вы создаете приложение, скорее всего, работа финансируется государством. Это означает, что она бесплатна для других и обычно с открытым исходным кодом. А когда что-то бесплатно, это означает, что обычно вы не несёте ответственности за то, чтобы оно всегда было доступно.

Потому что… ну, это же бесплатно.

Вы также не несёте ответственности за финансовый доход или конкретные результаты. Впрочем, работа программистом в научном учреждении — это тема для совершенно другой статьи.

Короче говоря, я ушла из института с большими ожиданиями.

Ожиданиями относительно того, как работает индустрия. Автоматические деплои. Пулл-реквесты и код-ревью. Это будет великолепно! Наконец-то качество кода, о котором я мечтала! Но кроме качественного кода с надлежащими стандартами и лучшими практиками, я твёрдо верила, что в софтверной индустрии все пишут тесты.

Хм...

Так что представьте моё удивление, когда в первый рабочий день в стартапе я не нашла никаких тестов. Никаких тестов в интерфейсе. Никаких тестов в бэкенде. Вообще никаких тестов.

Нда. Ничего. Ноль. NaN. Тесты отсутствуют как явление.

Не только не было тестов, но, казалось, никто не испытывал из-за этого проблем! С некоторой наивностью я предположила, что причина в том, что люди просто не знали, как писать тесты для AngularJS. Если я их научу, всё наладится — и мы начнём проводить тесты. Ошибка! В общем, только спустя несколько лет мы внедрили в код автоматические тесты, и это было не так просто, как я думала.

Но не потому, что люди не умеют их писать.

Они либо никогда не испытывали проблем от отсутствия тестов, либо испытывали проблемы от наличия старых тестов. Две вещи, с которыми я никогда не сталкивалась.

Что я в итоге поняла

У множества компаний и стартапов практически нет тестов. Сражаясь за рынок или за выживание, многие компании пренебрегают тестированием на ранних стадиях. Даже модные компании, которые спонсируют конференции или open source, часто делают большой неуклюжий монолит с минимальными тестами. Просто спросите у разработчиков о состоянии кодовой базы.

Ни у одной компании нет идеальной технической установки. У каждой компании проблемы, у каждой технический долг. Вопрос в том, что они с этим делают. При трудоустройстве нужно чётко понимать, что там не всё в порядке — иначе они бы не открывали вакансию.

Быть чрезмерно самоуверенным в вопросах, по которым вам не хватает реального опыта, довольно высокомерно. Я выступила ТАКОЙ всезнайкой, настаивая на повсеместном внедрении тестов, почти не имея опыта, как это действительно реализовать в большом масштабе. Не повторяйте моих ошибок. Важно иметь принципы, но важно ещё быть открытым и по-настоящему заинтересованным, чтобы воспринимать опыт и взгляды других людей.

3. Мы настолько отстали от всех остальных (aka техническая версия синдрома упущенной выгоды)

Это тесно связано с темой модульного тестирования. Моя компания не проводила тестов, но, конечно, все остальные компании их делали, верно?

Я прочитала кучу постов в блогах. Просмотрела массу выступлений с конференций на YouTube. Чёрт возьми, я непрерывно читаю «тот оранжевый сайт» [вероятно, имеется в виду Hacker News — прим. пер.]. Кажется, что все пишут суперсложные и высококачественные приложения с отличной производительностью и модными анимациями, в то время как я просто делаю заплатки, пытаясь успеть к дедлайну.

Я буквально боготворила все другие компании, о которых читала, и была разочарована тем, насколько моя компания и проект отстают от них.

Что я в итоге поняла

Многие выступления на конференциях охватывают доказательство концепций, а не реальные сценарии. Просто рассказ на конференции о какой-то технологии, не означает, что компания использует эту технологию в своей повседневной работе или что весь их код находится в идеальном виде. Часто ораторы на конференциях представляют игрушечные приложения, а не реальные применения: важно их различать.

Работать с легаси совершенно нормально. Нет, серьёзно, легко представить, что у какой-то другой компании нет легаси. Но проведя время на конференциях, разговаривая с людьми, работающими в топовых компаниях, становится ясно, что все мы в одной лодке. Попробуйте найти компанию, у которой НЕТ огромного монолита на PHP или Ruby, который они пытаются приручить (или должны были приручить в какой-то момент)? Легаси код — обычное дело, и работа с ним часто научит вас большему, чем создание приложений с нуля, потому что вы больше работаете с концепциями, которые ещё не понимаете.

4. Качество кода очень важно

В былые времена я могла сделать очень жёсткое код-ревью.

По крайней мере, я была весьма придирчива к стилю. Мой стиль оказался модифицированной версией стиля руководства по стилю JavaScript от Airbnb, но соответствует моим личным вкусам. Такие вещи, как отступы, форматирование, именование — не дай бог вы сделаете это иначе. Совершенно невозможно было пройти код-ревью без единого комментария от меня: вам пришлось бы освоить навыки чтения мыслей и вдобавок выиграть в лотерею.

Представьте более 50 комментариев к вашему пулл-реквесту с перечислением всех точек с запятой, которые вы пропустили!

Потому что у меня глаза как у орла — и этот орёл хочет получить все свои высококачественные точки с запятой!

(К счастью, после многих лет работы за компьютером зрение как у орла пропало, так что теперь вам не о чем беспокоиться — #шуткибезшуток)

Что я в итоге поняла

Достаточно хорошо — этого достаточно. При приближении к идеальному коду действует закон уменьшения отдачи. Код должен быть не идеальным, но достаточно чистым для работы и не полной катастрофой для поддержки. Часто код, который слишком повторяется или слишком подробный, легче понять другим людям. Кроме того, «хороший код» — не то же самое, что «код, который выглядит так, словно я сам его написал».

Архитектура важнее, чем придирки. Хотя какую-то строчку можно улучшить, но главные проблемы — архитектурного порядка. Лучше сразу сосредоточиться на структуре приложения, а не на отдельных крошечных фрагментах кода.

Качество кода важно, не поймите меня неправильно. Но качество кода — это не то, что я думала. Это не линтинг, форматирование или какой-то стиль, о котором рассказано в последней прочитанной мною статье.

5. Всё должно быть задокументировано!!!

Когда я пришла в свою первую настоящую компанию, я впервые вплотную столкнулась с чужим кодом. Конечно, я немного работала с чужим кодом на первой работе, но мне никогда не приходилось входить в существующую кодовую базу и выяснять, что, чёрт возьми, тут происходит. Единственный раз, когда такое случилось, я переписала весь код, вместо того, чтобы пытаться понять, как он работает.

В любом случае, совершенно не помог ситуации тот факт, что это был код AngularJS, написанный разработчиками Ruby, а я была джуниором, который мнил себя сеньором.

Итак, как я справилась с тем фактом, что 300 строк незнакомого кода заставили меня почувствовать, что я тону?

JSDOC. ПОВСЮДУ.

Я начала комментировать всё, чтобы попытаться найти смысл. Аннотации для каждой функции, до которой я могла добраться.

Я выучила весь этот причудливый Angular-специфичный синтаксис JSDoc. Мой код всегда был в два раза длиннее, потому что у него было столько документации и комментариев.

Что я в итоге поняла

Документация иногда врёт. Легко думать, что документация решает все вопросы. «Нам нужны доки!» Хотя документация — это тяжёлая работа, но её нужно делать. Просто следует документировать правильные вещи правильным образом. Чрезмерное документирование ненужных вещей, как правило, мешает людям, которые пытаются решить реальную проблему.

Где это уместно, сосредоточьтесь на автоматизации вместо документации. Тесты или другие формы автоматизации с меньшей вероятностью потеряют актуальность. Поэтому я стараюсь сосредоточиться на написании хороших тестов с ясным языком, чтобы другие разработчики могли увидеть, как функционирует проект с рабочим кодом. Другим примером является автоматизация установки приложения с помощью нескольких комментариев, а не длинного и подробного руководства по установке.

6. Технический долг — это плохо

Если после прошлого пункта вы посчитали меня невротиком, просто почитайте этот! Какое-то время в моей карьере я считала техническим долгом любой «грязный» код. Технический долг — забавный термин, потому что если вы попросите привести пример, назовывают очень разные вещи.

Поскольку я считала любой «неупорядоченный» код техническим долгом, я немедленно пыталась устранить его с максимальной строгостью!

Однажды я буквально провела выходные, вручную исправляя 800 ошибок линтинга.

Вот каким невротиком я была.

(Отказ от ответственности: это было до того, как появились автоматические исправления).

Что я в итоге поняла

Неорганизованный или беспорядочный код — не то же самое, что технический долг. Просто неидеальное состояние не означает, что это технический долг. Технический долг фактически замедляет вас каким-то образом, или делает определённые виды изменений трудными или подверженными ошибкам. Если код просто немного запутан, он просто немного запутан. Уборка может не стоить вашего времени.

Иметь некоторый технический долг — это нормально. Иногда мы сокращаем путь, потому что нужно выполнить работу срочно, и ради этого «одалживаем» часть времени в будущем. Наличие фрагментов кода, которые являются реальным «техническим долгом», нормально, если вы признаете, что вам, вероятно, придётся его вернуть. Если ваша кодовая база, на ваш взгляд, свободна от технического долга, скорее всего, вы переоцениваете внешний вид в ущерб доставке. И боже мой, как я его переоценивала!

7. Чем выше должность программиста, тем лучше он программирует

Начав программировать в довольно молодом возрасте, я стала настоящим профессионалом циклов for, отточив их до автоматизма за 15 лет. Программирование само по себе для меня как дыхание. Когда решение очевидно, я могу просто печатать код без остановок, как текст в блоге или электронной почте. Я могу закодировать решение быстрее, чем другие, и обычно брала на себя более сложные проекты.

Долгое время я думала, что именно в этом суть ведущего разработчика.

Вроде бы всё сходится? Ведь должность называется «ведущий разработчик», а не «ведущий коммуникатор» или «ведущий менеджер проекта». Я действительно не понимала, сколько ещё навыков нужно развить, чтобы стать по-настоящему «ведущим».

Что я в итоге поняла

Старшим инженерам придётся освоить много навыков, кроме программирования. Если сравнить с началом карьеры, мне пришлось развить астрономическое количество навыков. Коммуникация, управление зависимостями, совместное использование контекста, управление проектами, оценка сроков выполнения проекта и сотрудничество с коллегами, которые не являются разработчиками. Эти навыки с трудом поддаются количественной оценке и требуют много проб и ошибок, прежде чем будут усвоены надлежащим образом.

Не каждый программист станет «сеньором». Это результат многолетнего накопленного опыта. И всё же многолетний опыт — необходимое, но недостаточное условие для сеньора. Это должен быть ещё и правильный опыт, в котором вы усвоили правильные уроки и способны успешно применить эти знания в будущем. Иногда важные уроки проявятся через год или позже — вот почему годы опыта всё ещё имеют значение, даже если вы действительно хороший программист.

В некоторых областях мы всё ещё джуниоры. Независимо от того, сколько у вас опыта, всегда остаются места, где у вас мало знаний. Признание своей некомпетентности в конкретной области — первый шаг к заполнению этого пробела и получению помощи от более опытных товарищей.

Бонус: мне очень понравилась статья «Быть ведущим программистом». Отличная вещь, если в какой момент вы задаётесь вопросом, что подразумевает эта работа.

Обсудить на форуме