Примечание. Это продолжение статьи Что нужно, чтобы выделиться в качестве нового выпускника факультета компьютерных наук.

У тебя новая работа! Поздравляем!!! Теперь пришло время применить свои навыки и знания в реальном мире. Я видел довольно много младших разработчиков, прошедших через нашу команду в Education Perfect, многие из которых теперь являются старшими разработчиками, отличными кодерами и одними из моих самых надежных друзей. У каждого свой путь, но есть несколько закономерностей, и я могу дать несколько рекомендаций, которые помогут вам наилучшим образом начать работу на новом рабочем месте.

Приготовьтесь учиться

  • У вас есть прекрасная возможность понаблюдать за тем, как разработчики, которые давно этим занимаются, занимаются своим делом. Впитайте это!

Не бойтесь задавать много вопросов

  • Держите под рукой блокнот (или документ Google), чтобы записывать вопросы. Это нормально, когда у вас много вопросов, и здорово засыпать ими своего наставника. Тем не менее, помните, что у вашего наставника также будет своя собственная работа, поэтому вместо того, чтобы прерывать его каждые несколько минут другим вопросом, приберегите его для ваших запланированных встреч (которые, надеюсь, должны быть, по крайней мере, ежедневно в течение первых нескольких дней). недели).

Содействуйте везде, где можете

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

Ищите большую картину

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

Поймите своих пользователей

  • Не упускайте возможности пообщаться с вашими пользователями (а если нет, то хотя бы с командой разработчиков, которая, надеюсь, их понимает!). Это может быть немного страшно, но помните, что они тоже всего лишь люди. Это может включать посещение и наблюдение за сеансами пользовательского тестирования или непосредственное взаимодействие с клиентами, но это также может быть так же просто, как обращение по электронной почте к пользователю с просьбой лучше понять, чего он пытается достичь. Лучшие разработчики программного обеспечения проявляют сочувствие к своим пользователям и создают решения, которые понимают их потребности и решают их проблемы. Это помогает вам контекстуализировать работу, которую вы делаете, а также делает ее гораздо более значимой. Даже когда вы глубоко погружены в технические проблемы, понимание ваших пользователей позволит вам сделать прагматичный выбор в отношении того, на чем сосредоточить свои усилия, и в результате позволит вам выполнять задачи быстрее.

Знайте, что от вас ожидается

  • Убедитесь, что вы понимаете, что от вас ожидают в первые несколько месяцев. Не только ваши непосредственные роли и обязанности (хотя и их тоже важно понимать), но и то, как ваша команда хотела бы видеть ваше развитие в эти первые несколько месяцев. Помните, что человек, которого они наняли, — это не «вы прямо сейчас», а на самом деле «вы через 6 месяцев», с большим опытом и знаниями по работе с их системами. Ваша задача — как можно быстрее добраться от А до Б и начать приносить пользу, поэтому важно, чтобы вы понимали, как выглядит Б! Что вам нужно будет знать к тому времени? Какие навыки или компетенции вам нужно будет продемонстрировать? Если вы знаете, к чему стремитесь, вы можете сосредоточить свое внимание на достижении этой цели.
  • Это также отличный шанс спросить о ресурсах и поддержке, которые бизнес может предоставить, чтобы помочь вам на этом пути.

Отклеивание

  • Иногда вы застреваете и не знаете, что делать. Это нормально. Здесь существует интересный баланс между проявлением инициативы и поиском документации и т. д., чтобы попытаться найти ответ, и обращением за советом к наставнику. Я видел младших разработчиков на обоих концах этого спектра. Один из них целыми днями работал над куском кода, прежде чем обратиться за помощью, тогда как мы могли бы исправить его буквально за несколько минут. Другой замирал, когда они сталкивались с самым незначительным препятствием, и мы хотели, чтобы он проявлял немного больше инициативы в попытке решить свои собственные проблемы. Я бы посоветовал спросить вашего наставника, что он/она предпочел бы, чтобы вы делали, когда застряли. Если вы можете оставить эту конкретную часть кода в покое и тем временем продолжать работать с чем-то другим, то это, вероятно, оптимально. В противном случае отправьте им асинхронное сообщение (Slack и т. д.) с просьбой о помощи, а тем временем начните самостоятельно исследовать проблему.

Они собираются делать все по-другому

  • Не существует «правильного» способа создания программного обеспечения, но в течение следующих нескольких месяцев вы будете изучать, как это делают в этой конкретной компании. Часто в жизни нам нужны системы и стандартизация, чтобы иметь возможность эффективно сотрудничать, и именно то, что говорят эти правила или системы, часто менее важно, чем согласованность, которой они достигают, когда все их придерживаются. Например, посмотрите на вождение. Нет ничего более «правильного» в том, чтобы ехать по правой или левой стороне дороги, но очень важно, чтобы мы все согласились с тем, по какой стороне дороги мы едем, иначе был бы хаос! Процессы разработки тоже немного похожи на это. У большинства наборов процессов есть свои плюсы и минусы, и самое главное, что все члены команды понимают свой процесс и могут эффективно работать в нем. Процессы в вашей компании могут сильно отличаться от того, чему вы научились во время учебы в университете. Используйте это как возможность увидеть плюсы и минусы этого стиля по сравнению с тем, к чему вы привыкли. Обязательно поделитесь своими мыслями об этих различиях со своим наставником — они, вероятно, сочтут ваши идеи действительно интересными. В то же время примите тот факт, что в настоящее время системы вашей команды вряд ли радикально изменятся, и вам нужно будет подстраиваться под них. Со временем, опытом и доверием вы сможете выступать за системные изменения и улучшения. Ожидайте, что это займет некоторое время.

Это слишком много!

  • Ожидайте, что вы почувствуете себя не в своей тарелке, когда начнете просматривать кодовую базу. Операционные системы часто бывают большими и сложными, и они органично развивались в течение определенного периода времени, чтобы стать такими, какими они являются сегодня. Вы обнаружите некоторые вещи, которые не имеют смысла, если вы создаете код с нуля, но имеют смысл, сколько бы лет назад эта часть системы ни была изначально написана. Несмотря на самые лучшие намерения людей, вы найдете части системы с кодом, который трудно читать, и скудной (если вообще есть) документацией. А в большой системе просто тонна кода. Потребуется несколько месяцев, чтобы освоиться в окружающей среде, и с достаточно большой системой вы, возможно, никогда не узнаете все тонкости всего этого (и это нормально!).

Иногда вам будет нечего делать

  • У вас вполне могут быть периоды, когда вам нечего делать, или вам поручают «занятую работу». Не волнуйтесь — это не значит, что вы не нравитесь своей команде. Ваша команда будет находиться под всевозможным давлением, и иногда это будет означать, что время от времени вы будете немного отстранены. Используйте это время, чтобы изучить продукт, над которым они работают, и лучше понять, чего они пытаются достичь. Вы также можете просмотреть кодовую базу и лучше понять, как она устроена. Наконец, возможно, стоит провести какое-то соответствующее исследование или почитать, чем вы могли бы заняться в свободное время. Есть ли новый язык программирования, который вам нужно выучить для компании? Используют ли они фреймворки разработки, с которыми вы еще не сталкивались? Есть ли шаблоны кодирования, с которыми вы не сталкивались раньше? Все это может стать интересным чтением и исследованием, а также показать вашей команде, что вы вовлечены и заинтересованы, даже если для вас нет немедленного следующего шага.

Заводить друзей

  • Вы будете проводить много времени с людьми в вашем офисе в течение следующих 12 или более месяцев, так что вы можете с ними познакомиться!
  • Будьте немного смелее в столовой и начните разговор с членами вашей команды. Интересуйтесь ими как людьми, а не только их рабочими ролями. У них будут хобби и интересы, семьи, которые им небезразличны, и другие аспекты их жизни, о которых они, вероятно, не увидят в своей работе.

  • Скажите «да» любым приглашениям на социальные мероприятия с членами вашей команды. Разные команды имеют разную динамику относительно того, сколько времени они проводят вместе вне работы, но у большинства будет какая-то точка контакта (даже если они просто обедают вместе в некоторые дни недели). Вам не нужно заниматься чем-то, что вызывает у вас дискомфорт (например, я не пью алкоголь), но вы часто можете найти промежуточные решения (я все равно пойду на вечернюю вечеринку с напитками, даже если я останусь только на первый час и пить газированную воду).