Как программисту вести себя на новом месте работы

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

Сразу скажу, что в этот раз мы не будем разбирать ошибки верстки и программирования. На эту тему можно почитать другие статьи:

  • Распространенные ошибки начинающего HTML-верстальщика

  • 10 частых ошибок начинающих веб-разработчиков

  • Хорошие и плохие CSS-практики для начинающих

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

О каких правилах стоит знать заранее, чтобы не доставлять неудобства новым коллегам и начать работать эффективно с первого дня?

Совет №1. Не осуждайте

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

Совет №2. Роль — Проповедник

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

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

Совет №3. Игры в молчанку

Как мы уже поняли из первого совета, сложно увидеть всю картину целиком, только придя в компанию. Продукт разрабатывался долгое время многими разработчиками (только если это не стартап). Многое будет вам непонятно и не очевидно. Самый плохой в этой ситуации сценарий — это замкнуться в себе и пытаться разобраться самостоятельно.

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

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

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

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


Совет №4. Не игнорируйте правила

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

Обязательно прочитайте их все. По возможности запомните или держите под рукой. Тут все как в уголовном кодексе: незнание не освобождает от ответственности.

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

Если вам не дали никаких документов, то обязательно уточните этот момент у руководителя. Возможно, единого документа еще не сформировано (никто не любит писать документацию). В этом случае попросите рассказать на словах, как все устроено в компании.

Совет №5. Изучайте обстановку

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

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

Рассмотрим пример. Дано: Вы — верстальщик. Вас просят сверстать страницу для нового раздела сайта.

Неверным решением будет немедленно и с рвением приступить к верстке с нуля.

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

Совет №6. Pull-request и code-review

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

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

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

Совет №7. «А вот на прошлой работе»

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

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

Хотя если наоборот, то иногда можно.

Совет №8. Читайте по слогам

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

Совет №9. Человекопонятно

Старайтесь писать код так, как будто завтра вы передадите его другому человеку. Есть большая вероятность, что вас в ознакомительных целях посадили на одни задачи, а в дальнейшем вы будете заниматься чем-то другим. Комментируйте свой код. Документируйте код. Оформляйте код по всем правилам. Тогда вам не придется все объяснять на пальцах коллеге, когда наступит время передать код.

И не стоит забывать, что вы можете не пройти испытательный срок Хороший код можно будет положить в портфолио.

Совет №10. Будьте на связи

Будьте готовы к тому, что первое время вопросы будут возникать не только у вас, но и к вам. Некоторые коллеги (возможно и начальник) работают далеко не с 9 до 18. Это значит, что ответ от вас может потребоваться в нерабочее время. Возможно, задача, над которой вы работали, довольно срочная и выкатывать ее начали в выходной. Не выключайте телефон или будьте онлайн.

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

Удачи вам на новом рабочем месте!

P.S. Слайды с этими рекомендациями в формате «вредных советов» можно посмотреть на Гитхабе.

Полный текст статьи читайте на Нетология