Алек, сделай

Дубай - часть 1

Главное отличие этого Нового года от всех предыдущих в том, что в жанр "открыток из вотсапа" стали попадать изображения из генеративных моделей.

Это ли не киберпанк?

Весь мир: *борется с нелегальным контентом*
Банки в РФ: уникальная возможность стать продактом-пиратом!

Открытый вопрос

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

Теперь ему интересно, как джуну можно быстро прокачаться до миддла?

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

Терпеть не могу код ревью (4/4) - Общение

В завершающем посте расскажу про нашу внутреннюю кухню: как мы пофиксили коммуникацию, сделав ее комфортной и понятной для всех участников процесса.

Коммуникация в интернете - это, на мой взгляд, самостоятельный навык, которому надо учиться, как правописанию или ораторскому мастерству. В реальной жизни, помимо слов, мы также используем невербалику: интонации, жесты, мимику, образы. В сети же у нас ограниченный набор инструментов для донесения своих мыслей. Мы можем использовать скобочки, эмодзи, изображения или даже описывать, какой интонацией наше сообщение надо “прочитать”. Но все это оказывается тщетно, когда сообщения доходят до получателя: сколько бы усилий и красок в текст вы не вложили, интерпретация зависит от контекста и привычек оппонента. Так случилось и у нас.

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

Посудите сами, что было тогда:
🔝 “Это не должно работать”
🔝 “А вот это вообще можно было лучше сделать”
🔝 “Уже есть функция, которая делает ровно тоже самое”
🔝 “У нас так не принято, переделай”

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

Что мы сделали, чтобы это исправить:
🔝 Поделили комментарии к коду на несколько типов и сформировали формат сообщения
🔝 Ревьювер объясняет, почему он оставил этот комментарий
🔝 Если ревьювер видит необходимость переписать решение, то к комментарию прилагаются указания / инструкция / вариант решения / ссылка на источники с пояснениями (используй код-ревью как еще один канал для обучения и менторства)
🔝 Поощряем использование эмодзи в комментариях
🔝 Хорошие решения стоит подмечать и давать позитивную обратную связь
🔝 Ввели анекдоты к пулл реквестам (по желанию)

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

❗️Обрати внимание:
В проекте это значение используется ещё несколько раз. Думаю, ее можно вынести в константы, чтобы повысить читаемость.

❓ Есть вопрос:
Почему ты решил остановиться именно на этой библиотеке? Смотрел ли в сторону *Library_name*? Судя по описанию, она работает быстрее и весит меньше.

🚀 Возможность для улучшения:
Кажется, здесь компонент будет перерисовываться много раз на странице из-за изменения состояния. Попробуй вынести его отдельно и кешировать, чтобы избежать замедления работы. *Пример кода по возможности*

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

Кстати, сегодня у Яндекса стартует новый сезон тренировок, в этот раз по трём направлениям:
- Алгоритмы
- ML
- DevOps

Бесплатно, на месяц и с возможностью попасть в штат по упрощённой схеме. Сам попробую заскочить на трек ML, присоединяйтесь!

Если вам когда-нибудь было интересно, как ChatGPT так хорошо может отвечать на ваши сообщения, то очень рекомендую бесплатный Стэнфордский курс по NLP:
YouTube-плейлист
Домашки и практические задания

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

10/10

Собеседования дизайнеров

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

Собес у дизайнеров - это, оказывается, отдельный удивительный мир. Чтобы вы понимали, из чего состоит типичное собеседование для разработчика:
1. Прескрининг с HR: могут задать вопросы по теории, в которых сам HR ничего не понимает, но за ошибки отсекут уже здесь
2. Технический собес:
- Рассказ о своем опыте + к рассказу могут последовать более глубокие технические вопросы
- Устная секция “вопрос-ответ” по основам языка программирования и необходимой базе, без которой ты не сможешь работать
- Лайв-кодинг с углубленными вопросами, с озвучиванием размышлений, с объяснениями решений, со спорами, дискуссиями и т.д.
3. Собес на софт-скиллы или, как мы его называем, на адекватность
По желанию еще +2 собеседования по алгоритмам и углубленной теории (Яндекс, привет)

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

Тем временем собес на дизайнера:
1. Прескрининг на софт-скиллы
2. Еще один собес на софт-скиллы + "а фигму можете показать? А компоненты умеете? А автолейауты могёте? Нет, прямо сейчас не нужно делать, мы видим, спасибо"
3. Последний собес на софт-скиллы

Если это не идеальная IT-профессия, то что тогда?

Спойлер к следующей серии

Терпеть не могу код ревью (3/4) - Регламент

Мой первый PR (pull/merge request - запрос на внесение изменения в код проекта) в рамках нашего нового процесса провисел несколько суток и задержал релиз. Дискуссия под моим кодом с каждым днем только увеличивалась: коллеги продолжали спорить над тем, что уже было исправлено, и начинали новые ветки комментариев под теми частями, за которые не успели зацепиться ранее.

Чтобы не повторять такой опыт, мы договорились о регламенте ревью, который установил рамки в этом процессе:
- Все, что не относится к целям ревью (из предыдущего поста) - не является предметом ревью.
- Ответственный за PR - его автор. Он следит за тем, чтобы ревьюверы не забыли прожать галочку, когда код можно вливать в основную ветку.
- Разработчик вправе не исправлять каждое замечание.
- Однако, есть критичные замечания, которые обязательны к исправлению. Такие ревьювер должен выделять, чтобы они не затерялись среди других комментариев.
- Концептуальные вопросы выносятся на обсуждение в общий чат и позднее закрепляются в стайл гайде (та самая страничка в нашем confluence/wiki), куда можно ссылаться в следующий раз.
- Ревью подлежит только новая функциональность, но не исправления багов.
- Критикуя, оставляй предложения.
- Ревью не только для замечаний: узнали что-то новое из PR своего коллеги, или увидели, что качество кода возросло - отметьте это и похвалите.

После этого мы договорились об ограничениях в сроках проверки PR. Это было нужно, чтобы не затягивать ревью на несколько дней. Помимо этого, определили минимальное условие, необходимое для вливания кода в основную ветку:
- PR “живет” всего 24 часа. Это означает, что у ревьюверов есть только сутки на то, чтобы дать комментарии, а у разработчика - исправить замечания.
- Если за первые 4 часа никто не прокомментировал PR, то разработчик должен попросить об этом в общем чате. Это нужно, чтобы не надоедать каждые полчаса напоминаниями о проверке.
- PR может быть влит в основную ветку только после подтверждения хотя бы одного из ревьюверов.

Как итог, за сутки жизни PR можно успеть прокомментировать только основные недочеты. Огромные ветви обсуждений при регламентированных сроках стали непродуктивными. Больше никаких ревью на несколько дней, долгих дискуссий и споров под твоей работой о том, как правильно писать код, и в какой шараге учат этому лучше.

Ну а чтобы все было совсем хорошо, мы договорились избегать коротких неконструктивных комментариев по типу “Мы так не пишем, переделай”. По двум причинам:
- Само по себе такое сообщение хоть и экономит секунды жизни ревьювера, но никак не ведет к конструктивному диалогу.
- Разбор того, а как в итоге правильно писать, затягивается надолго, поэтому и есть правило “критикуя, предлагай”. Тем самым, автор PR не дожидается следующих комментариев коллеги.

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

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

Терпеть не могу код ревью (2/4) - Цели

Итак, первая попытка в код-ревью прошла ужасно: мы сорвали сроки, много времени решали, как правильно писать код, а как - нет, и настроение в команде было напряженное.

Мы собрались на разбор полетов, и каждый высказал свое видение, почему наш опыт был неудачным. Вдруг кто-то спросил: “Мы столько времени потратили, сорвали сроки, перессорились, может, нам вообще не проводить ревью?”. Вопрос встретила тишина, потому что за всеми спорами мы забыли про цели, которые мы преследуем, внедряя код-ревью.

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

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

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

Если разработчик отдал код на ревью, который по своей архитектуре отличается от того, к чему привыкли остальные - такая штука не пройдет проверку. Да, если мы сейчас вольем эту фичу, то уменьшим Lead Time в моменте (и порадуем заказчика), но значительно проиграем в этой же метрике позже, когда начнем дорабатывать этот грязный код.

Чтобы писать код так, как принято в команде, мы завели отдельную страничку в confluence (вики) и верхнеуровнево описали наш подход и ключевые моменты, на которые стоит обратить внимание + расшарили на всех настройки IDE и почти выровняли правила для линтеров между проектам.

✅ Команда знает, что происходит в проекте
Зачем нужна эта цель: снижение скорости роста кодовой базы, понимание взаимосвязи компонентов и корректная оценка трудозатрат при планировании.

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

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

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

✅ Находить лучшее решение совместно
Зачем нужна эта цель: уменьшение багов, снижение техдолга, обучение сотрудников.

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

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

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

———————————————————————

Казалось бы, зачем эти цели, кто еще не знает, для чего нужно ревью? Для синхронизации. Без определения того, что мы ждем в результате введения процесса, нам было сложно договориться о том, на что мы смотрим в ходе проверки: что важно, а что второстепенно - у каждого свое видение.

Ок.