Всем привет, меня зовут Борис, я iOS и Android-разработчик. Сегодня я хочу поделиться своими наблюдениями о том, с какими проблемами встречается новичок в IT, устроившись на работу, и как вообще выглядит сам процесс.

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

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

А еще напоминаю, сейчас я занимаюсь менторингом и помощью начинающим в iOS, потому вы всегда можете написать мне в личные сообщения по любому вопросу в telegram: verbitckii_b

Приятного чтения!

С чего начинается работа?

Итак, поздравляю, вот вы получили первый в своей жизни IT-офер, и, кажется, самое сложное уже позади! Вы огромный молодец, проделали большую работу, преодолели все сложности с большой конкуренцией и, наконец, получили то, что так давно желали. А теперь приготовьтесь, что с этого момента вам будет еще сложнее!

Получение техники

Вероятность, что вам выдадут рабочий ноутбук по моим оценкам примерно 80%. Наверное, только самые маленькие компании не могут себе этого позволить, потому на них я выделил 20% вероятности. Этот момент лучше уточнить при обсуждении офера. Компьютер такой не всегда самый свежий и мощный (чаще всего не самый свежий и не самый мощный). Например, мне в одной большой компании пришел MacBook Pro 13 на i7 с 16 гигабайтами оперативной памяти 2019 года. Это не плохой компьютер, но было очень грустно билдить огромный 8 гигабайтовый проект по 30 минут на холодную каждый раз при смене ветки в git. И еще грустнее, что рядом стоял мой MacBook Pro 16 M1 тоже с 16 гигабайтами оперативной памяти, который справился бы с этой задачей быстрее раза, наверное, в 2, а то и больше. Убедить работодателя настроить личный ноутбук под работу - очень непростая задача, хоть и реалистичная (главное - убедить безопасников). Компьютер, к слову, пришел в таком состоянии, что как будто на нем резали салат, и не работал один usb-с порт (как вообще на маке можно сломать usb-c порт?). А надо ли упоминать про закаменевшие разводы на экране, которые, наверное, остались после эмоциональных дейликов? Ну ничего, у меня, слава богу, был внешний большой монитор, моя любимая механическая клавиатура и подключив рабочий комп, я почти не чувствовал разницы, кроме, конечно, ощутимых просадок по производительности.

В другой большой компании ситуация была чуть получше, потому что мне прислали MacBook Pro 16 на i7 с 16 гигабайтами оперативной памяти. Да и проект сам был поменьше, потому здесь в этом плане было сильно лояльнее. Правда, техника тоже повидавшая, как будто разрабы до меня ноут и правда использовали в качестве разделочной доски на кухне. И стреляют в него из слюнявого дробовика. Окей, не проблема, все равно компьютер всегда у меня работал в закрытом состоянии благодаря внешнему монитору и клавиатуре.

Какова мораль этого пункта:

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

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

Онбординг

Честно говоря, я еще не встречался с тем, что я представлял себе, говоря слово "онбординг". Не то, чтобы у меня прям требования какие есть, но вот основные тезисы, которые я предполагал:

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

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

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

С чем я сталкивался на самом деле:
Знакомство с процессами было во всех компаниях, но это что-то типа идеологической накачки вроде "мы сила, мы команда" и т.д. Были и подробности о том, как, например, разруливать конфликты через комплаенс, какие-то пожарные требования, как, например, должен быть выстроен git flow в команде и тд, но все это, к сожалению, было в отрыве от реальности. У меня возникло ощущение, что кому-то из топ-менеджеров пришла чудесная идея, что новичков надо знакомить с процессами, но реализация этой идеи настолько не в цель, что, придя в команду, - там все равно все по-своему. И это немного грустно, но терпимо.

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

Введения в проект тоже не сказать, что было. При входе тебе дают старшего, которого ты можешь спрашивать о чем угодно. Только вот нюанс, обычно это старший разработчик, у которого самые большие требования от бизнеса, и он занят ВСЕГДА, потому что он все знает лучше всех, и у него куча своих задач. Потому не всегда получалось достучаться, дозвониться и потому чаще было проще самому искать решения или торпедировать других участников команды. Документацию я ни на одном проекте не видел, комментарии в коде очень скромные, никаких роадмапов не было. Процесс обучения обычно выглядит так: тебе дают баги, ты их решаешь, потом тебе дают другие баги, ты их тоже решаешь, и, когда ты начинаешь это делать уверенно, дают задачи посложнее. Баги тоже разные бывают, иногда это совсем что-то безобидное, а в другом же случае может быть какой-то мамонт, который уже пытались и до тебя решить, и он не решался, как повезет, в общем.

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

В общем и целом, не получится придти на готовенькое, комфортный процесс работы придется построить себе самому. Это не проблема, к этому просто надо быть готовым и учиться этому, если не получается сразу.

Задачи

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

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

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

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

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

Дейлики

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

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

Общая атмосфера

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

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

Заключение и вывод

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

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

Хорошего дня и удачи!

PS. Для тех, для кого все пункты выше не стали преградой, и он до сих пор хочет стать iOS разработчиком, пишите мне в telegram: verbitckii_b. Я помогаю с планом обучения, проверкой знаний, курирование pet-проектов, code review и тд.