Помню, когда я искал работу и изучал кучу материалов о высоких технологиях, обучении программированию, читал истории успеха, больше всего внимания я уделял тому, как найти работу. Но мне всегда было любопытно, что же будет, когда ты уже начнешь работать. В статье я постараюсь ответить на этот вопрос.
Как прошел первый день, первая неделя, первый месяц? Есть ли какие-то навыки, которые не пригодятся на собеседовании, но будут необходимы с самого начала работы? Даже если я уже получил работу, как понять, что я готов качественно с ней справляться?
Общая информация
Я занимаю должность разработчика в компании Human API в Сан-Матео, Калифорния. Это стартап, занимающийся технологиями в сфере здравоохранения, со штатом примерно в 35 человек. В основном он ориентирован на обмен медицинскими данными, ориентированный на пользователя. Я работаю в качестве front-end разработчика, используя React, Redux и Sass.
Первый день
Первый день был почти нереальным. Я давно мечтал о том, чтобы быть разработчиком, и первый рабочий день показался мне сном. Я попытался наладить контакт с коллегами, поговорив со всеми в офисе.
Мне дали “Путь новичка к успеху”, который включал следующие пункты:
- Первый день — настроить ноутбук, сходить на приветственный ланч;
- 1-я неделя — научиться рисовать диаграммы, касающиеся работы продукта, познакомиться с Agile, полностью адаптироваться;
- 2-я неделя — создать что-то, используя наш общедоступный API, устранить баг, добавить расширение;
- 1-й месяц — начинать брать ответственность за свою часть продукта;
- 1-й квартал — отвечать за свою часть продукта полностью.
Но, в основном, ожидаемо, первый день был посвящен установке необходимой рабочей среды на мой ноутбук.
Первая неделя
Первая неделя была примерно такой же. Всё та же настройка моего оборудования, чтение руководств для новых сотрудников и т.д.
Было так непривычно программировать днем в будни! Еще я привыкал к обычным для стартапов фишкам. Мой менеджер постоянно звал меня “экспертом React”, потому что меня наняли в качестве главного front-end разработчика в этой команде. Я не понял, действительно ли он считал меня экспертом или же просто пытался задрать планку. В любом случае, я старался принимать это, как есть.
Я также изучал Agile. Каждый день у нас проводились 15-минутные “стенд-ап” собрания, где каждый мог встать и рассказать о том, над чем они сейчас работают, и мешает ли кто-то их работе.
Вот что волновало меня, когда я подавал своё резюме:
Насколько плохо, что я не разбираюсь в Agile, Scrum, velocity, инкременте продукта, спринте, ретро…?
Я считаю, что до того, как вы начнете работать, вам не нужно знать ничего из этого. Эти знания могут пригодиться на собеседовании, потому что, если вы покажете, что разбираетесь в этом, интервьюер подсознательно будет считать вас более подходящим, но на самом деле, в процессе работы вы сможете изучить эти понятия менее, чем за день.
Первый месяц
К этому времени я уже занимался реальной разработкой и был действительно полезен для команды. Я учился работать с дизайнером, менеджерами по продукту и другими разработчиками. Иногда я работал из дома, что было здорово. Я понял, что это, в целом, позволяет мне работать более продуктивно. Похоже, всем было все равно, когда ты приходишь в офис и когда ты уходишь, что разительно отличалось от моего предыдущего места работы. И ещё, по сравнению с предыдущей работой, у меня было намного меньше собраний.
Раньше я не пользовался Sass, поэтому посмотрел пару видео и почитал несколько документов. Он очень похож на CSS, поэтому не было ничего сложного. Проект, над которым я работал, был довольно новым, поэтому ещё не было строгих, стандартных действий с Git. Честно говоря, на этом этапе всё было очень похоже на то, как я создавал свои проекты для портфолио. И тут была ещё одна проблема, которая меня волновала…
А достаточно ли я разбираюсь в git? Что если я столкнусь с чем-то сложным в Git и всё испорчу?
Я думаю, что опыт работы с Git в команде будет весьма ценным. Ходите на курсы программирования и создавайте какой-нибудь проект, участвуйте в хакерских марафонах, работайте с общедоступными источниками. Разберитесь с pull, push, merge и rebase. Испытайте всю боль разрешения конфликтов слияния. Почитайте о самых лучших способах работы с git.
Вы можете учиться в процессе работы, но вы будете работать намного эффективнее, если уже придете с каким-то опытом работы с git.
Ещё одна проблема, с которой я часто сталкивался в течение первого месяца: я не понимал, что делать, когда работа зашла в тупик. Стоит ли попросить помощи у кого-то или пробиваться самому?
От работы программистом я ожидал, что вокруг меня будут более опытные и умные люди, которые смогут помочь, если я буду в тупике.
Когда же вы учитесь сам по себе, у вас нет такой роскоши, и вам приходится выбирать: биться ли головой о стену перед вами или искать другую стену, чтобы биться уже о неё.
И тогда я понял: самообучение программированию дало мне важный навык. Теперь я понимаю, сколько мне нужно биться головой о стену, прежде чем попытаться найти обходной путь или попросить чьей-то помощи. А если вокруг вас постоянно полный офис наставников, готовых помочь при любой проблеме, вам никогда не придется проходить все мучения выбора, что делать дальше, если вы в тупике.
Ваш настрой НЕ должен быть:
Ух ты, смотрите! Вокруг меня целый офис разработчиков, которые могут мне помочь!
или:
Он должен быть таким:
Я постараюсь разобраться с этим сам, и если мне нужно будет попросить кого-то помочь, я расскажу ему, что попытался сделать.
6-й месяц
К этому времени я уже адаптировался к коду, моей команде и компании в целом. Мы всей компанией были на пикнике, отмечали выпуск продукта в пивоварне. Проводили игровой вечер, когда каждый приносил любимую видеоигру, а так же чемпионат мира в офисе и другие мероприятия. Но в то же время много нервов и сил ушло на создание различных версий продукта.
Я перенимал опыт множества умных людей, старался высказывать своё мнение по определённым моментам. Я побыл интервьюером на собеседованиях, участвовал в различных проектах. Также я всё больше работал с бэкендом, и в итоге мне это понравилось больше всего.
Очень сложно оценить, сколько времени занимает добавление новых элементов/устранение багов, но мне кажется, что в этом направлении я намного лучше не стал.
Я думаю, что самой сложной и проблемной (но также интересной и приносящей удовлетворение) частью работы стал дизайн и архитектура. Если нужно добавить какой-то элемент, в моей голове сразу же появляется несколько способов сделать это, но очень сложно выбрать лучший из них с учетом затрат времени.
Иногда добавление каких-то элементов требует долгих обсуждений со многими людьми. А иногда вам приходится всё решать самому, потому что на это не стоит тратить время, несмотря на то, что вы не можете придумать хорошего решения. И тогда через 3 месяца вы смотрите на свой код примерно вот так:
FAQ
В этом разделе я отвечу на часто задаваемые вопросы, которые могут возникнуть у новичков.
Я все свои силы трачу на обучение программированию… Как понять, что мне понравится быть разработчиком?
Если вам нравится программирование, то, думаю, вам понравится работать программистом. Это не значит, что любая работа программистом будет прекрасной, и вам точно понравится любая. И даже если вы получите отличную должность разработчика, это не означает, что вам будет в ней нравиться абсолютно всё.
Но если вам нравится создавать что-то новое, перестраивать ужасный код, наконец, устранять баги, которые надоедали вам долгое время, значит, всё будет хорошо. Если вам нравятся трудности обучения программированию, то разработка приложений — это ваше.
Даже если я уже получил работу, как понять, что я готов качественно с ней справляться?
Почему-то я всегда считал, что есть огромная разница между людьми, которые работают программистами, и мной (человеком, который не работает программистом). То есть, этот вопрос очень часто всплывал и в моей голове.
Я согласен с избитой фразой: “Если вас наняли, значит вас считают готовым к этой работе”. Я твердо верю, что нужно всё решать поэтапно. Если у вас нет работы, сосредоточьтесь на её поиске. Когда же вы нашли работу, вы можете сосредоточиться на том, что вы должны делать, чтобы справляться с этой работой.
Если вы одновременно переживаете о поиске работы и вашем гипотетическом успехе на гипотетической работе, вы просто добавляйте лишний стресс и переживания в свою жизнь.
Есть ли какие-то навыки, которые не пригодятся на собеседовании, но будут необходимы с самого начала работы?
Повторюсь и скажу, что мой главный ответ на этот вопрос: не переживайте о своей гипотетической работе, пока она не станет реальной.
Однако, если “нет” для вас не ответ, советую вам то, о чем упоминал ранее. Попробуйте поработать над проектом в команде и постарайтесь научиться лучшим способам работы с Git.
Уверен, вы найдете множество статей на эту тему, если поищите, например: “основы работы с Git”. Мне здесь больше особо и нечего добавить, кроме как посоветовать развивать личные качества. С первого дня постарайтесь подружиться со своей командой и со всеми в компании.
В чем самое большое отличие работы в одиночку от работы в команде или в стартапе?
На самом деле, это зависит от уровня продукта, над которым вы работаете. Наибольшая разница заметна при работе с крупным продуктом, которым будут пользоваться множество людей. Вот некоторые аспекты, о которых вы можете не думать, при осуществлении своих второстепенных проектов, но которые важны при создании широкомасштабного приложения в стартапе:
- Безопасность — Конечно, вам не обязательно заботиться о ней в ваших второстепенных проектах. Но если вы работаете на продуктом, которым будут пользоваться множество людей, интернет-безопасность крайне важна.
- Совместимость с браузерами — Возможно, вам придется поддерживать версии для IE, что означает отказ от новейших фич в CSS и может привести к проблемам с JS. И тут нужно уделить время кроссбраузерному тестированию.
- Аналитика — Возможно, вы будете пользоваться чем-то вроде Google Analytics или Mixpanel, чтобы иметь представление о конверсии и уровне использования продукта.
- Тестирование — Вам точно не придется прописывать тесты для ваших собственных проектов, если вы не хотите. Однако, тестирование очень важно для написания хорошего кода. Чем дольше во время обучения программированию вы тянете с тем, чтобы начать писать тесты, тем сложнее будет превратить это в привычку.
- Блокирующие дефекты — Вам, наверняка, придется полагаться на то, что кто-то должен что-то сделать, прежде чем вы сможете создать свой элемент. Поэтому вам всегда нужно иметь обходные пути. Если вы front-end разработчик, а API всё ещё не готов, вам придется создать имитацию API, чтобы вы смогли работать с интерфейсом пользователя.
- Поддержка — Конечно, вы хотите писать хороший код для своих личных, второстепенных проектов, но ставки там не так высоки. Скорее всего, вам не придется поддерживать этот код в течение года, поэтому какая разница, что в нем нет комментариев и весь код в одном большом файле, правда? При работе в команде нужен низкий порог для участия в работе. То есть, если к проекту подключается новый человек, нужно, чтобы он почитал руководства, увидел код и сразу же начал принимать участие в работе. Если код тяжело понять и прочесть, это не только усложнит участие новых людей в работе, но и затруднит добавление новых элементов без значительного технического долга.
Последний совет
Как я уже много раз говорил, не думаю, что важно знать всё это до того, как вы получите работу. Я считаю, что некоторое понимание этих аспектов будет ценным, но не обязательным.
Также, к сожалению, бывают интервьюеры, которые будут спрашивать у вас что-то из того, о чем шла речь в статье. Может быть, потому что они не могут придумать что-то получше, а может, потому что они проводят собеседования на более высокие должности. Я же считаю, что все эти вещи можно изучить уже в процессе самой работы, если у вас есть прочная база.
Удачи!
Перевод статьи Austin Tackaberry: What I’ve learned six months into my first job as a self-taught software engineer
