За год невозможно вырасти из стажера-разработчика в уверенного профессионала. Зато можно получить много других ценных уроков и инсайтов. Чего ждать, если вы только начинаете свой путь в программировании? Какие советы начинающий разработчик слышит от старших коллег каждый день? Об этом моя сегодняшняя статья.
Свой путь в IT я начала чуть больше года назад. Решив попробовать себя в программировании, я пришла на стажировку в компанию Mad Devs. Уже во время стажировки я получила первый опыт командной разработки в реальном проекте. После я продолжила работу во внутренних и коммерческих проектах как младший фронтенд-разработчик.
Здесь нет универсальных наставлений всем начинающим свой путь в разработке. Я не могу претендовать на роль гуру для новоиспеченных программистов, я сама всё еще новоиспеченный программист. Но если вы только начинаете карьеру в IT, мой опыт может быть вам полезен.
Урок первый. Коммуникация
Существует распространённое заблуждение: коммуникация необязательна, чтобы работать в IT. Многие до сих пор думают, что работа программиста на сто процентов состоит из написания кода. На самом деле это не так. Давайте разберемся, почему.
Разработка приложений — это сложный процесс, в котором участвует много людей: фронтендеры и бэкенд-разработчики, DevOps-инженеры, дизайнеры, проектные менеджеры, тестировщики, заказчики. Всем им нужно не только понимать общее направление работы, но и обсуждать детали конкретных задач, договариваться о сроках их исполнения. Иногда требуется и решать конфликты.
Таким образом, день разработчика в командном проекте чуть ли не наполовину состоит из коммуникации: стендапы, командные созвоны, рабочие онлайн-сессии. Синхронизированные действия позволяют ускорить разработку и повысить её эффективность. Даже на фрилансе не обойтись без созвонов с заказчиком и уточнения деталей.
Если вы не считаете коммуникацию своей сильной стороной, не переживайте, ей можно научиться. Коммуникация — это навык, который можно и нужно активно развивать. Ниже мы еще поговорим о конкретных проблемах коммуникации в командной работе. А сейчас хочу посоветовать две книги, которые помогут прокачать скилл коммуникации:
Урок второй. Ответственность
Вот что пишет об ответственности Дядюшка Боб в своей книге “Идеальный программист”:
“Термин «профессионализм» имеет много смысловых оттенков. Конечно, профессионализм — это своего рода почетный знак и повод для гордости, но также он является признаком ответственности. Понятно, что эти стороны профессионализма неразрывно связаны между собой: нельзя гордиться тем, за что вы не несете никакой ответственности.
Быть непрофессионалом намного проще. Непрофессионалы не несут ответственности за выполняемую работу — они оставляют ответственность своим работодателям. Если непрофессионал совершает ошибку, то мусор за ним прибирает работодатель. Но если ошибка совершается профессионалом, то устранять последствия приходится ему самому.”
Если разработчик берет задачу в работу, он должен доводить ее исполнение до конца. Это значит — до продакшна, до реальных пользователей. То есть работа над задачей завершается не тогда, когда она передана на тестирование. Задача выполнена тогда, когда изменения протестированы, находятся на продакшене, и их видят реальные пользователи.
Это значит, что с самого начала и до конца разработчик несет ответственность за фичу. Он должен найти решение. Он может пойти к другому разработчику, попросить помощи или создать ему задачу, протестировать ее, отправить на тестирование ответственным лицам. На нем же лежит ответственность за то, чтобы вовремя сообщить о проблемах, попросить помощи у старших коллег, напомнить проверить пулл реквест, предупредить о том, что не успевает по срокам.
Таким вещам, как правило, можно научиться, перенять как философию у старших коллег, более опытных программистов. И, конечно, читайте дядюшку Боба. Например, вот его доклад, где он формулирует заповеди программиста.
Урок третий. Просьбы
Поскольку я начинающий разработчик, я постоянно обращаюсь к своим коллегам — мне от них нужен совет, помощь или фидбек. Иногда мне кажется, что я уже достала всех своими вопросами.
У меня есть выбор. Вариант первый: не беспокоить коллег и попытаться разобраться самостоятельно. Как правило, на это уходит много времени, часто это чревато срывом сроков. В условиях реального проекта с определенными дедлайнами это не лучшее решение. Второй вариант — это перебороть в себе страх потревожить человека и решить свою задачу более быстро и эффективно. С внешней помощью, да.
Урок третий. Просьбы
Поскольку я начинающий разработчик, я постоянно обращаюсь к своим коллегам — мне от них нужен совет, помощь или фидбек. Иногда мне кажется, что я уже достала всех своими вопросами.
У меня есть выбор. Вариант первый: не беспокоить коллег и попытаться разобраться самостоятельно. Как правило, на это уходит много времени, часто это чревато срывом сроков. В условиях реального проекта с определенными дедлайнами это не лучшее решение. Второй вариант — это перебороть в себе страх потревожить человека и решить свою задачу более быстро и эффективно. С внешней помощью, да.
Вот небольшая инструкция о том, как правильно просить помощи:
- Попытайтесь разобраться в проблеме самостоятельно. Скорее всего, Google поможет вам найти ответ. Не тратьте на это больше 30–60 минут.
- Попробуйте изложить проблему в письменном виде так, будто вы пытаетесь объяснить ее коллеге. На этом этапе ответ часто появляется сам собой. Такой прием называется “утиным дебаггингом”. Не тратьте на это больше 60–90 минут.
- Если решить проблему самостоятельно не удалось, то попросите коллегу найти для вас немного (или много) времени в течение дня. Кратко расскажите, с какой проблемой вы столкнулись.
- Если вам обещали помочь, максимально подробно расскажите о проблеме. Сообщите как можно больше деталей, предоставьте сообщения в консоли, логи. Расскажите, что вам удалось нагуглить, объясните, как вы уже пытались решить проблему.
- Также может сработать вариант, когда вы подробно расписываете проблему и отправляете ее в чат команды или общий чат отдела разработки. Возможно, кто-то из коллег поможет вам с решением.
Задавайте больше уточняющих вопросов. Если что-то вам не ясно, не бойтесь показаться глупым, спрашивайте, пока не поймёте. Так вы сэкономите свое время и время других людей. Помните: если вы чего-то не поняли, вам придется вернуться к этому позже и потратить дополнительное время. Спрашивать и уточнять всё равно понадобится.
Отдельно расскажу про фидбек. Начинающим программистам сложно объективно оценить свою работу. Поэтому нужно регулярно просить отзывы у товарищей по команде и старших коллег. Это позволит выявить свои сильные и слабые стороны, понять, на что стоит обратить внимание и над чем работать.
Урок четвертый. Проблемы
В командной разработке очень важно вовремя говорить о проблемах. Чем раньше вы скажете о том, что вас беспокоит, тем быстрее вам помогут советом или делом.
Когда вы…
- понимаете, что не справляетесь с задачей,
- слишком много времени потратили на решение конкретной задачи,
- понимаете, что близки к срыву сроков,
- даже не знаете с чего начать,
- заблокированы обстоятельствами или другими членами команды,
ГОВОРИТЕ об этом!
Многие процессы в командной разработке направлены как раз на раннее обнаружение возможных проблем и их быстрое решение. К таким процессам относятся, например, ежедневные стендапы и регулярные командные созвоны.
Стендап — это рассказ о том, что вы сделали по задачам вчера, что будете делать сегодня. Также в стендапе вы указываете, с какими проблемами столкнулись. Отдельная графа для проблем выделена не случайно. Ваша задача — сообщить о проблемах. В команде есть выделенный человек, проектный менеджер (ПМ), задача которого — помочь вам решить эти проблемы.
Каждый раз, когда вы замалчиваете проблемы, где-то в мире грустит один ПМ — ваш ПМ.
Урок пятый. Боязнь ошибаться
У меня есть проблема — я боюсь делать ошибки. Опасаюсь не успеть к дедлайну, подвести коллег, разочаровать заказчиков. Этот страх мешает мне браться новые задачи, потому что я боюсь с ними не справится. Это мешает развиваться, потому что всё неизвестное меня пугает.
Если вы тоже чего-то боитесь, знайте: это нормально. Важно понимать несколько простых истин. Они могут показаться банальными, но они помогают успокоиться и разрешить себе делать ошибки.
Во-первых, невозможно знать и уметь все. Особенно в современной IT-сфере, которая очень быстро меняется.
Во-вторых, ошибки все равно будут. Разработчики не роботы, они не могут писать идеальный по определению код. Тем не менее, надо стремиться совершенству, то есть помнить о прежних ошибках и не повторять их снова.
В-третьих, без ошибок нет развития. Совершая ошибки, мы получаем бесценный опыт. Все уроки, описанные в этой статье — это знания, приобретённые путём выявления ошибок и исправления факапов, как своих собственных, так и общекомандных.
Об ошибках писал Роберт Мартин в уже упомянутой мной книге “Идеальный программист”:
“Программный код слишком сложен, и ошибки будут всегда. К сожалению, это не избавляет вас от ответственности. Человеческое тело слишком сложно, чтобы изучить его от начала и до конца, но врачи все равно клянутся не причинять вреда. И если уж они не пытаются уйти от ответственности, то с какой стати это может быть позволено нам?
«Хотите сказать, что мы должны писать совершенный код?»
Нет, я хочу сказать, что вы должны отвечать за свое несовершенство. Тот факт, что в вашем коде заведомо будут присутствовать ошибки, не означает, что вы не несете за них ответственность. Написать идеальную программу практически невозможно, но за все недочеты несете ответственность именно вы, и никто другой.”
Урок шестой. Работа на результат
При командной разработке IT-продуктов используется много разных инструментов и методологий. Возможно, вы слышали о некоторых из них: OKR, Agile, SCRUM и т.п. Кому-то кажется, что это лишние процессы, которые только отнимают время. Но важно, чтобы вся команда понимала общие цели и приоритеты. За этим и нужны методологии. Это делает процесс разработки гибким и структурированным.
Команда должна понимать цели своей работы, знать, какую проблему она решает, какую ценность приносит. Иначе это monkey business — работа ради работы, просиживание штанов в офисе в ожидании конца рабочего дня.
Поэтому всегда нужно стремиться узнать больше о целях проекта, даже если ваш менеджер их вам не объяснил в подробностях. Проявите инициативу, разузнайте больше о проблемах заказчиков. Продумайте все возможные варианты поведения пользователя. Копните глубже и найдите, как еще можно улучшить разрабатываемый продукт.
По завету старших коллег, постоянно спрашивайте себя: “А не хуйню ли я делаю?”
Урок седьмой. Оценки задач и сроки
Умение оценивать задачи в разработке — это целое искусство, которому надо учиться. Но есть одно правило, которое решит половину ваших проблем с оценками задач — никогда не соглашайся на сроки, в которых не уверен.
Вновь обратимся к книге “Идеальный программист”, где Дядюшка Боб приводит пример диалога о сроках между разработчиком и менеджером.
Майк: «Пола, страница входа в систему мне нужна к завтрашнему дню».
Пола: «Нет, Майк, здесь работы на две недели».
Майк: «Две недели? По оценкам проектировщиков, работа должна была занять три дня, а прошло уже пять!»
Пола: «Проектировщики ошибались, Майк. Они выдали свою оценку до того, как служба маркетинга сформулировала окончательные требования. У меня осталось работы еще на 10 дней. Ты не видел мои обновленные оценки в вики?»
Майк: (с суровым видом и недовольным голосом) «Это недопустимо, Пола. Завтра я буду представлять клиентам демо-версию, и я должен им показать, что страница входа работает».
Пола: «Какая часть страницы входа должна работать к завтрашнему дню?»
Майк: «Мне нужна страница входа! Я должен иметь возможность войти в систему».
Пола: «Майк, я могу сделать макет страницы входа, который позволит войти в систему. Сейчас простейший вариант уже работает. Макет не проверяет имя пользователя и пароль и не отправляет забытый пароль по электронной почте. У верхнего края нет баннера с фирменным логотипом, не работает кнопка справки и всплывающая подсказка. Страница не сохраняет cookie, чтобы запомнить данные для следующего входа, и не устанавливает ограничений доступа. Но войти в систему вы сможете. Подойдет?»
Майк: «Значит, вход будет работать?»
Пола: «Да, вход будет работать».
Майк: «Отлично, Пола, ты меня спасла!» (отходит с довольным видом)
Не переоценивайте себя и не давайте ложных обещаний, иначе получите бессонные ночи, много овертайма и злого ПМа.
Финальная черта
Всё это мне удалось вынести из моего первого года в IT, первого в жизни опыта командной разработки. Это был сложный год, но он принёс мне множество инсайтов и открыл мне новый мир. Дальше будет только интереснее.
Благодарности
В конце хочется поблагодарить всех своих коллег и менторов, в частности, Denis Grushkin, Emir Sabyrkulov, Vladimir Shebarshov и Alice Jang. Спасибо вам! Благодаря вам и вашему терпению я у мамы программист и пишу вот такие умные статьи =)
Спасибо за внимание!
