Советы по программированию для Junior-разработчиков

Анастасия Игошева

frontend-разработчик в компании Space307

Я занимаюсь фронтенд-разработкой в Space307, помогаю студентам Яндекс.Практикума в качестве ментора и в свободное время веду свой YouTube-канал Story[it] by Igosheva, где рассказываю о том, как же всё-таки «войти в айти»

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

Как правило, работодатели принимают сотрудников за hard skills, а увольняют или повышают по карьерной лестнице за soft skills, это уже давно не секрет.

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

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

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

1. Принимая задачу, чётко обговорите с заказчиком, какого результата необходимо достигнуть. Если у каждого из вас видение результата будет отличаться, с высокой долей вероятности вы не сделаете то, что от вас требовали. Или же наоборот — сделаете то, о чём вас не просили.

Крайне важно оценить сроки реализации и сопоставить их с ожиданиями заказчика. Если сроки не реалистичны — сразу говорите об этом. Скорее всего, это не с вами что-то не так, и вы медленный/глупый, а от вас действительно требуют нереального. В этой ситуации предложите упрощённый вариант решения задачи (mvp) или возможное готовое решение.

Сразу определитесь с количеством правок: поверьте, это упростит жизнь и вам, и заказчику.

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

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

3. Во время реализации задачи обязательно уточняйте у тимлида/заказчика все спорные вопросы, не принимайте решение самостоятельно. В моей карьере бывали моменты, когда самостоятельное решение вопросов по принципу «наверное, они имели в виду вот это» не совпадали с реальным видением заказчика и приходилось очень долго и больно переделывать.

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

5. Очень важно проверять промежуточный результат на соответствие с первичными договоренностями с заказчиком задачи. Если этого не делать, вы можете не заметить, как в середине задачи уйдёте от намеченного курса или же отстанете от дедлайна.

6. Относитесь к ревью и тестированию, как к возможности прокачаться и получить новые знания. Учитесь учиться через других, впитывать чужие знания и опыт. Я часто вижу ситуации, когда начинающие специалисты неверно трактуют ревью от коллег, думая, что до них «докапываются» или даже хотят унизить. Пока не встречала ни одного ревьюера с такой целью, скорее наоборот: их цель — научить вас через подсвечивание ошибок и зон роста.

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

Подводя итоги, хочется еще дать несколько общих советов:

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