Первые полгода в должности разработчика: чему я научился

Перевод статьи Остина Текаберри «What I’ve learned six months into my first job as a self-taught software engineer».

Я разработчик-самоучка. В этом посте я поделюсь тем, что я усвоил за первые полгода работы в компании. Здесь не будет советов о том, как получить работу. Также прошу учесть, что пост касается только моего опыта – и только в одной компании.

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

Каким будет первый день, первая неделя, первый месяц? Есть ли какие-то навыки, которые для собеседований не важны, но лучше бы их иметь, когда приступишь к работе? И даже если я найду работу, как быть уверенным, что я с ней справлюсь, и справлюсь хорошо?

Бэкграунд

Я работаю на позиции разработчика в компании под названием «Human API» в Сан-Матео (Калифорния). Это тех-стартап, в нем около 35 сотрудников. Работаем мы с данными из сферы охраны здоровья. Меня наняли разработчиком с фокусом на фронтенд и использование таких технологий как React, Redux и Sass.

Первый день

Первый день был в достаточной мере сюрреалистическим. Я уже некоторое время мечтал о подобной работе, так что первый день был наполнен ощущением сбывшейся мечты. В качестве ice breaker (игры для легкого вхождения в коллектив) у меня был поиск сокровищ, в ходе которого мне нужно было пообщаться со всеми в офисе.

Мне выдали «План успеха новичка», который включал такие вещи как:

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

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

Первая неделя

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

Было так странно целый день писать код! Я все еще привыкал к обычным штучкам стартапа Залива.

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

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

Это была одна из тех вещей, о которых я немного волновался, когда искал работу.

Сильно ли это плохо, что я не знаком с agile, scrum, velocity, product increment, спринтами, ретроспективами?..

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

Первый месяц

К этому времени я уже занимался настоящей разработкой и вносил свой вклад в общее дело. Я учился работать с дизайнером, продукт-менеджером, другими инженерами.

Временами я работал дома – это было прекрасно. Оказалось, что периодическая работа дома в целом повышала мою продуктивность. Создавалось такой впечатление, что всем безразлично, когда ты приходишь в офис или уходишь куда-то. Это очень отличалось от моей работы в предыдущей компании. У меня также было ГОРАЗДО меньше собраний, чем на прежней работе.

До того я не пользовался Sass, так что мне пришлось посмотреть какие-то видео и почитать документацию. Он очень похож на CSS, так что особых проблем не было.

Тот проект, над которым я работал, был совершенно новым, так что там не было каких-то строгих, стандартизированных подходов к работе с git. Честно говоря, на этом этапе разработки все было удивительно похоже на то, как я разрабатывал свои проекты для портфолио.

Была еще одна вещь, о которой я беспокоился на стадии собеседований.

Достаточно ли хорошо я знаю git? Что, если на работе будет какой-то сложный рабочий процесс, а я все перепутаю?

Я думаю, что некоторый опыт использования git в команде будет довольно ценным. Присоединитесь к местному сообществу и создайте проект вместе с новыми знакомыми. Примите участие в хакатоне. Поучаствуйте в open source. Пусть pull, push, merge, rebase станут для вас привычными вещами. Пройдите сквозь боль работы с конфликтами слияния. Почитайте о лучших подходах к работе с git.

Научиться всему этому можно и на работе, но будет эффективнее, если у вас уже будет опыт работы с самыми обиходными вещами.

Также на протяжении первого месяца мне часто случалось застрять с какой-то задачей и я не знал, что мне делать. Должен ли я обратиться к кому-то за помощью или, напротив, должен справиться сам?

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

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

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

Не стоит воспринимать рабочую ситуацию как «Вау, вы только посмотрите! Тут целая комната разработчиков, которые могут мне помочь!».

Должно быть что-то вроде «Я постараюсь разобраться с этим самостоятельно. Если мне все же потребуется помощь, я расскажу человеку, к которому обращусь, что именно я перепробовал и каковы были результаты».

Шестой месяц

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

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

Очень сложно оценивать, сколько времени займет добавление фичи или исправление бага. Похоже, даже со временем мне не становится легче это делать.

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

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

FAQ

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

Я приложил все усилия, чтобы научиться программированию. Но как мне узнать, понравится ли мне заниматься разработкой?

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

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

Даже если я получу работу, как мне знать, что я сумею справиться со своими обязанностями, причем хорошо?

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

Я согласен с распространенным ответом: «Если вас наняли, значит, вы готовы к выполнению этой работы». Я большой сторонник постепенности. Если у вас нет работы, фокусируйтесь на том, как ее получить. Устроившись на работу, вы сможете сфокусироваться на том, как сделать так, чтобы быть успешным на этом месте.

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

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

Повторюсь: не переживайте о гипотетической работе, пока она гипотетическая. Но если такой ответ вас не устраивает, то, как я уже говорил, можно поработать над каким-то проектом в команде, чтобы потренироваться обращаться с git. Я уверен, по этой теме вы найдете массу статей.

Также стоит отрабатывать базовые soft skills. Старайтесь ладить с вашей командой и вообще со всеми, кто работает в той же компании, с самого первого дня.

В чем главная разница между созданием собственного проекта и работой в команде в стартапе?

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

• Безопасность. Об этом без лишней необходимости мало кто беспокоится при создании сторонних проектов. Но когда вы работаете над продуктом, которым будет пользоваться множество людей, веб-безопасность очень важна.
• Браузерная совместимость. Вам может случиться поддерживать версии IE, а это значит, что вы не сможете использовать все прекрасные новейшие особенности CSS. Также могут возникнуть проблемы с JS. Поэтому необходимо межбраузерное тестирование, а это отдельная проблема.
• Аналитика. Чтобы разобраться в конверсиях и используемости продукта можно воспользоваться Google Analytics или Mixpanel.
• Тестирование. Вы определенно можете не писать тестов для собственного проекта, если не хотите. Но для написания хорошего кода тестирование необходимо. Учась программировать, начинайте писать тесты как можно раньше, потому что сложнее всего перевести это в привычку.
• Блокировщики. Вы можете зависеть от работы другого человека, который должен что-то сделать, чтобы и вы могли начать работать. Возможно, придется подумать, как все устроить. Если вы фронтенд-разработчик, а API еще не совсем готов, возможно, придется создать макет API, чтобы вы смогли работать с UI и не оказались заблокированным.
• Поддерживаемость. Конечно, вы стараетесь писать хороший код и для своих собственных проектов, но там ставки не столь высоки. Может, через год вы уже и не будете поддерживать свой проект, так что какая разница, что в его коде нет комментариев, а весь он лежит в одном огромном файле.При работе в команде нужны низкие барьеры для принятия участия. То есть, когда в проект входит новый человек, он должен иметь возможность почитать доки, посмотреть код – и после этого быстро начать участвовать в работе. Если код труден для чтения и понимания, то это не только задержит начало работы новых людей. Это еще и усложнит добавление нового функционала (без одновременного добавления существенного технического долга).

Заключение

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

Также, к сожалению, отдельные интервьюеры могут вас спрашивать об этих вещах. Может, потому что не знают, что спросить, может, потому что ищут кого-то на более сеньорскую позицию. Но я думаю, что, если у вас есть хорошие профессиональные знания, все эти вещи можно изучить уже на работе.

[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]