Привет! На связи Митя Кожевников и Юра Соколов из Mindbox, и это третья, финальная часть гайда по софтам для джунов. В первой части мы говорили о том, что значит «приносить пользу» в разработке. Во второй — об ориентации на результат. В этой части речь пойдет о развитии: что делать, чтобы расти быстрее.
О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах.
Некоторые советы могут звучать очевидно: например, у нас есть пункт «учиться на ошибках» — понятно, что никто не планирует из раза в раз косячить на ровном месте. Но часто именно таких простых советов тяжело придерживаться. Поэтому в статье мы «приземлили» их реальными историями, чтобы читатель мог узнать ситуацию, если столкнется с ней сам, и применить наш гайд.
Кому читать. Этот гайд — для джунов, которые хотят сделать софты своим конкурентным преимуществом. Если джун ответственно выполняет работу, умеет самостоятельно обучаться и не проходит мимо говна, его готовы оторвать с руками, даже если ему не хватает знаний. К тому же советы из этого гайда помогут быстрее закрепиться в команде и вырасти. Пользуйтесь!
Совет 1. Задавать вопросы
Вопросы позволяют учиться у более опытных коллег, раскапывать нюансы, которые на старте не видны и в книжках не описаны. Поэтому быстрее растут те джуны, которые постоянно задают вопросы.
Чтобы на вопросы отвечали, важно уметь их задавать. Есть три полезных привычки:
Перед тем как спросить, искать ответ самостоятельно. Не стоит закапываться и сидеть часами — достаточно 15–30 минут. Обычно за это время находят ответы на простые вопросы, либо погружаются в тему и потом лучше воспринимают ответы, обсуждают вопрос детальнее — в любом случае это облегчает работу наставника.
Говорить, где и как искали ответ. Например, «в ранбуках и карточке посмотрел, в Google поискал». Благодаря этому собеседник понимает, что вы действительно проделали подготовительную работу, — так отвечать на вопрос приятнее. К тому же он видит уровень погруженности и может адаптировать под это ответ.
Проверять решение, а не просить его дать. Если есть возможность, лучше сформулировать предположения и попросить их оценить — собеседнику проще это сделать, чем придумывать и расписывать решение с нуля.
Задача | ❌ | ✔️ |
На время окна обслуживания (maintenance) отключить инфраструктуру поставки новых данных в аналитическую систему (шипинг) | Ребят, кто знает, как отключить шипинг? | Ребят, мне надо отключить шипинг на время обслуживания, но я не знаю как. Посмотрел по коду и докам. Отключить шипинг, как будто, можно запросом <пример запроса>. Не вру? |
Оптимизировать запросы в базу данных, которые занимают слишком много времени | Помогите с медленными запросами разобраться ? | Привет! Добавил индексы на столбцы, которые чаще всего используются в WHERE и JOIN, но это не помогло. Вот структура таблицы и пример медленного запроса: <детали>. Провел анализ EXPLAIN для запроса и получил следующие результаты: <детали>. У вас есть идеи, как еще можно оптимизировать этот запрос? |
На старте бывает страшно задавать вопросы: кажется, что они слишком глупые или неуместные. Но спрашивать можно и даже нужно. Если очень некомфортно, попробуйте взвесить цену ошибки: если есть риск сломать прод, лучше лишний раз переспросить.
Митя Кожевников
У меня есть наглядный пример, когда вопрос сэкономил кучу времени. У стажера была задача оптимизировать алгоритм построения отчета. После внесения изменений нужно было убедиться, что логика расчета осталась прежней: сравнить результат пересчета до и после модификации.
Когда стажер начал сравнивать два отчета, он обнаружил, что сохранил себе не тот отчет. Чтобы исправить ситуацию, он хотел откатить изменения и перезапустить старую версию алгоритма, но решил обсудить свой план с ментором. Ментор предложил другой способ извлечь результаты прошлого пересчета, который позволил стажеру сэкономить время на ожидании повторных пересчетов и выкладок.
Митя Кожевников
Вторая история обратная — когда незаданный вопрос привел к проблеме. У стажера была задача изменить синтетические данные в отчете в демо продукта. Для этого нужно было завести новую таблицу для хранения данных и по готовности переключить код сервиса на работу с новой таблицей с помощью feature toggle (об этом процессе рассказывали в статье про релизный цикл).
Чтобы подключить новую таблицу, нужно было проделать дополнительную работу в промежуточном сервисе. Стажер этого не знал, отложил регистрацию таблицы в сервисе, и переключил feature toggle раньше времени — в итоге не получил ожидаемого результата и на демо пропали данные.
Избежать этой ситуации помог бы вовремя заданный вопрос. Как данные из таблицы попадают в отчет? В какой момент можно переключить feature toggle? А еще лучше, если бы стажер принес ментору на валидацию план переключения: «Добавляю данные в таблицу, переключаю feature toggle и регистрирую таблицу в сервисе. Всё верно?» Ментор бы сразу его остановил.
Совет 2. Учиться на ошибках
Ошибки — это нормально, их делают все. Плохо повторять ошибки раз за разом. Чтобы не делать этого, полезно писать постмортем.
Постмортем — это письменный разбор причины факапа. Он состоит из ответа на вопросы:
Что произошло?
Какие события предшествовали этой ситуации?
Какая первопричина проблемы?
Что поможет устранить первопричину и избежать ошибку в следующий раз?
Пример заполненного постмортема
Ситуация: не уложился в срок с объемной задачей. Что предшествовало: сначала написал всю логику, потом начал прикручивать к ней тесты, из-за чего архитектура разъехалась и пришлось переделывать свеженаписанный код. Первопричина: не учел тестируемость при написании кода, потратил много времени на переделку. Как избежать: буду начинать реализацию с теста. Прочитаю статьи и книги о Test Driven Development, которые посоветовали коллеги. |
В постмортеме важно найди корневую причину факапа — в этом помогает метод пяти «Почему?», которые последовательно задают к каждой причине. Также важно сформулировать конкретное действие, благодаря которому ошибка не повторится.
❌ | ✔️ |
Тест был косячный, в следующий раз буду внимательнее | Написал вечнозеленый тест. В следующий раз начну с красных тестов и буду править код до их озеленения |
Юра Соколов
Первые 3 года я ввёл список своих факапов в гугл-документе: где накосячил, в чем причина, почему так поступил, чему научился и что сделать в следующий раз по-другому.
Я перечитывал документ каждую неделю, чтобы ошибки отложились в голове и я больше не повторял их.
Совет 3. Ставить цели
Цели в профессиональном развитии полезны по трем причинам:
Проще сохранять фокус. Когда направление зафиксировано, проще понять, что ему соответствует, а что — нет. Например, в целях — прокачивать навык проектирования. Тогда стоит найти сеньора, который прямо сейчас что-то проектирует, и попробовать помочь ему. А вот интересные задачки про новую технологию лучше пока отложить.
Юра Соколов
На старте я столкнулся с расфокусом. Мне нравилось быть разработчиком, но помимо этого меня привлекала роль наставника и скрам-мастера. Я не стал выбирать между направлениями и попытался делать все: и код писал, и встречи проводил, и к подготовке стажеров подключился.
Из-за большой нагрузки стал выгорать, но благо вовремя отловил это состояние и уменьшил скоуп. Теперь инвестирую одновременно в 1–2 направления и не пытаюсь охватить сразу все.
Виден прогресс. С целями процесс развития становится не бесконечным, а итерационным. В конце каждой итерации можно оглянуться и подвести итог — стало ли лучше. При этом проще авторизовывать результат — есть измеримый результат и конкретные цели, которых удалось достичь.
Формируются взаимные ожидания с командой. Если цели публичные, команда понимает, в какую сторону развивается специалист, чего от него ждать, а чего — нет.
Юра Соколов
Когда я понял, что хочу развиваться в сторону в скрам-мастера или менеджера, сказал об этом ведущему и команде. Это помогло всем: когда нужно было провести встречу, команда понимала, к кому обратиться, а я получал возможность попрактиковаться в том, что мне интересно.
Чтобы поставить профессиональные цели, можно использовать методику OKR — Objectives and Key Results. OKR состоит из двух компонентов:
Цели (Objectives) — вариант будущего, который хочется достичь. Он должен быть крупным и амбициозным настолько, что выполнить его даже на 70% — уже круто. Например, стать мидлом и получить повышение или оффер на новое место; довести пет-проект до релиза; затащить сложный проект, например, редизайн главной страницы.
Ключевые результаты (Key Results) — измеримые показатели, чтобы отслеживать прогресс в достижении цели. Они должны быть конкретными, ориентированными на действие и служить показателями успеха или неудачи.
Пример OKR
Цель — устроиться веб-разработчиком на фуллтайм.
Ключевые результаты:
1 месяц. Начать обучение на двух онлайн-курсах по фронтенд-разработке.
2 месяц. Построить и развернуть три персональных проекта, используя изученные технологии (например, HTML, CSS, JavaScript).
3 месяц. Получить обратную связь от опытных разработчиков по проектам и улучшить их согласно предложениям. Завершить онлайн-курсы. Пройти 10+ техсобесов и получить хотя бы 2 оффера.
Чек-лист быстрого профессионального роста
Если в какой-то момент кажется, что прогресса нет, это можно проверить, ответив на несколько вопросов:
Задаю ли вопросы, когда что-то непонятно? Пытаюсь найти ответ сам? Помогаю собеседнику ответить мне: проговариваю, где искал ответ, и формулирую решение самостоятельно?
Какие ошибки совершил за последнее время? Какие из них произошли не впервые? Что делаю, чтобы не повторять их и те, что произошли в первый раз?
Есть ли глобальная цель, к которой двигаюсь? Насколько я близок к ней? Какие ключевые результаты уже достигнуты? Какие в работе? Что я делаю для того, чтобы достичь цели?
Бонус: что прочитать, что научиться ставить цели по OKR
? Больше о работе и росте разработчиков в Mindbox — на странице с рассказами наших нынешних и бывших сотрудников.