В минувшие выходные мне довелось пообщаться с несколькими студентами, только что получившими диплом. Они ищут свою первую работу инженера-программиста. В ходе беседы с ними я выяснил, что у них довольно неправильное представление об этой работе.
Реальность у этих новичков очень сильно искажена. Они видят только хорошую зарплату, удаленную работу, тимбилдинги и вечеринки с пиццей.
Все это хорошие преимущества, но никто не говорит с ними о реальных вещах, которые происходят на работе.
Как человек, который провел много лет в этой отрасли, я открыл им глаза на реальность. Я рассказал им о хороших вещах, но также и о некоторой правде, которую трудно проглотить.
Прочитав эту статью, некоторые люди скажут, что я говорю об этом слишком негативно, но я считаю, что эти вещи сопутствуют работе, и вы должны принять их.
1) ВУЗ не подготовит вас к работе
Это первое, что я объяснил этим ребятам.
Чтобы точно описать, как колледж подготовит вас к работе, представьте, что вы учитесь плавать.
Ваш инструктор тратит огромное количество времени на то, чтобы описать вам все движения, которые вы должны делать. Он заставляет вас повторять все эти движения, задает вам вопросы по ним, у вас экзамены по ним. Но вы никогда не касаетесь воды.
Через 5 лет вы получаете бумажку, подтверждающую ваше умение плавать. И вот наступает день, когда нужно плыть. Ребята в плавательном зале просто бросают вас в воду.
Вам трудно дышать, вы боретесь за свою жизнь. Может быть, вы утонете, а может быть, вам удастся выплыть.
Именно так выглядят первые 6 месяцев для только что окончившего ВУЗ студента, работающего инженером-программистом.
В колледже вас подготовят к каким-то основам, но то, чему учат в большинстве колледжей, очень далеко от повседневной работы. Большинство профессоров, преподающих в университетах, не являются хорошими инженерами-программистами.
Лишь небольшой процент из них когда-либо работали инженерами-программистами. Кроме того, университетские учебные программы сильно устарели. Они отстают на годы от потребностей рынка разработки программного обеспечения.
Во время учебы в ВУЗе нужно дополнительно работать. Помимо домашних заданий и семинаров, выполняйте больше проектов. Занимайтесь волонтерской деятельностью. Изучайте разные сферы бизнеса, чтобы подготовиться к предстоящей работе.
Большинство студентов этого не делают. Они ждут, когда получат диплом, чтобы начать работать над своим портфолио.
2) Вы редко будете получать новые красивые проекты
В колледже или учебном центре вы получаете множество небольших заданий, которые вы пишете с нуля. Полная свобода самовыражения. Вы можете реализовать все те фантастические вещи, которые изучаете, например, алгоритмы или паттерны проектирования.
Время, которое вы тратите на выполнение таких заданий, составляет максимум несколько недель, но чаще всего — пару дней работы. Как правило, такие задания содержат не более 500 строк кода.
В повседневной работе вы работаете с проектами, содержащими множество уровней и тысячи строк кода. Над этими проектами одновременно работает несколько человек. Свобода действий ограничена, приходится подстраиваться под проект. Время, которое вы проводите в проектах, обычно составляет от полугода до пары лет.
Иногда вы тратите целую неделю на исправление неприятной ошибки. А исправление — это всего лишь пара строк кода. Вы общаетесь со своими коллегами. Вы обмениваетесь информацией о проекте. Вы сотрудничаете с ними, чтобы получить одобрение своего решения.
Новые проекты появляются редко, и чаще всего вы работаете над уже существующими. Можно считать, что вам повезло, если вы получили нормальный проект, а не какой-нибудь старый legacy проект.
3) Всем наплевать на ваш чистый код
Вы можете забыть о том, что ваш начальник скажет вам: «Поздравляю вас с написанием такого элегантного и чистого кода, я повышу вам зарплату!». Наоборот, всем наплевать на ваш чистый код.
Не поймите меня неправильно, люди ожидают, что вы будете писать хороший и чистый код. Но похвалу за это вы получите редко. Разве что иногда от коллег, которые будут просматривать ваш код.
Для некоторых новичков это может быть шоком, но это вполне логично. Ваша основная задача как инженера-программиста — создавать ценности для пользователей. Написание кода — это лишь один из этапов достижения этой цели.
Можно представить это как следующий цикл:
- инженер-программист пишет код
- пользователи получают новые возможности
- все больше пользователей используют ваши продукты
- компания получает прибыль от продуктов
Таким образом, код — это всего лишь инструмент для получения прибыли.
Я видел очень много проектов с ужасными устаревшими кодовыми базами. Тем не менее, эти проекты успешны, поскольку имеют шикарные лендинги и решают проблемы пользователей. Поэтому пользователи с удовольствием платят за их использование.
Пользователь не знает, как выглядит кодовая база. Он просто видит, какие возможности предлагает данный продукт. Поэтому не стоит слишком сильно привязываться к чистоте и элегантности кода. Сосредоточьтесь на своевременной поставке функции без ошибок.
4) Иногда приходится работать с некомпетентными людьми
У людей есть предубеждение, что в ИТ-индустрии работают только умные и компетентные люди. Особенно в области разработки программного обеспечения. Но это далеко не так.
Как и в любой другой работе, в вашем окружении иногда будут попадаться некомпетентные люди. Работать с ними очень неприятно. Они тратят много времени и создают токсичную обстановку. Кроме того, они крайне непродуктивны. Все это отражается на сроках и приводит к задержкам. Это стоит компаниям денег и ресурсов.
К сожалению, у меня тоже был опыт работы с такими людьми. Должен сказать, что они настолько хорошо истрепали мои нервы, что я потратил немало времени на то, чтобы придумать, как обойти их некомпетентность.
Вот несколько советов:
- Cтарайтесь быть эффективным и продуктивным настолько, насколько это возможно, сосредоточьтесь на себе, а не на них.
- Пробуйте другие варианты/решения, не вовлекающие этих людей в процесс.
- Документируйте все, что вы делаете — если что-то пойдет не так, у вас будет доказательство некомпетентности.
- Если вы заблокированы из-за того, что какой-то человек не выполнил свою работу, попробуйте попросить кого-то другого разблокировать вас (если это возможно).
- Говорите с ними напрямую, будьте профессиональны, но не грубы, и скажите что и как они могут улучшить.
Помните, что не нужно вести себя с такими людьми грубо.
Иногда вы не знаете всей истории. Мне приходилось сталкиваться со случаями, когда человек просто не может выполнять свою работу должным образом. На них наваливается масса задач, и они делают работу за двоих.
5) Привыкните к многочасовым совещаниям
Совещания — важная часть работы разработчика программного обеспечения. Некоторые из них приносят пользу, а некоторые просто отнимают время.
Есть повторяющиеся встречи, которые проводятся ежедневно или еженедельно. Большинство из них не являются продуктивными. Большинство из них проводятся по принуждению человека, который их организует, потому что это единственная «работа», которую он делает.
Это просто пустой протокол, подтверждающий цель его существования в компании.
С другой стороны, существуют продуктивные совещания. Такие совещания обеспечивают обмен информацией между членами команды или разных команд.
Большинство инженеров-программистов ненавидят митинги. Но помните, что ваша работа заключается также в открытом и активном общении.
Обмен информацией крайне важен для продвижения проектов. Когда вы делитесь информацией, это может помочь другим командам лучше понять, что вы делаете и наоборот.
6) К вам будут часто обращаться за оценкой сроков
Бизнес вращается вокруг цифр. Каждый проект имеет свою стоимость, и чтобы рассчитать ее, руководству необходимо оценить, сколько времени потребуется на создание той или иной фичи.
Затем инженеры-программисты оценивают свою работу. Обычно сметы составляются с учетом времени, но иногда они также просят оценить сложность работы.
Во многих ситуациях вы не имеете ни малейшего представления о том, сколько времени потребуется на создание того или иного объекта. Вы читаете требования, проводите исследование и называете цифру.
Позже, когда вы начинаете работать над этой функцией, вы сталкиваетесь с множеством проблем, о которых вы не знали, когда давали оценку времени. Тогда приходится компенсировать потери и надеяться, что сроки не будут сорваны.
Поэтому всегда полезно обещать меньше, но сделать больше.
Например, когда руководитель проекта просит вас реализовать функцию X к пятнице, вы не скажете «О, я могу закончить ее ко вторнику». Вместо этого вы скажете: «Конечно, без проблем».
Почему?
Потому что, если вы пообещаете выполнить проект ко вторнику и столкнетесь с проблемами, вы не сможете выполнить обещание. Если же вы примете пятницу как крайний срок и закончите работу к среде, то сможете выполнить ее на 2 дня раньше.
Существует множество формул для составления планов разработки, и у каждого свои правила. У меня тоже есть свои правила.
Если мне нужно сделать какую-то функцию, и я думаю, что это займет 2 дня, я добавляю к этому примерно 40% времени, чтобы перестраховаться. Таким образом, в этом случае расчетное время составит 3 дня. В дальнейшем, если я закончу работу за 2 дня, я могу просто сдать ее раньше.
7) Ошибки станут вашим заклятым врагом на всю жизнь
Чем больше вы программируете, тем больше осознаете, что ошибки в коде встречаются повсеместно. Когда вы только начинаете программировать, вам кажется, что вы что-то напишете, оно будет работать нормально, и на этом все закончится.
Но на самом деле все обстоит иначе. Существует бесчисленное множество вещей, которые могут привести к ошибкам:
- Ваш собственный код — люди совершают ошибки, и не стоит доверять тому, что код работает идеально. Вы можете написать тесты, но ошибки могут возникнуть и после этого по разным причинам, о которых вы даже не подозреваете.
- Библиотеки сторонних разработчиков — эти библиотеки также написаны инженерами-программистами, такими же, как мы с вами. Всегда следите за активностью и частотой обновления этих библиотек.
- Аппаратные сбои — программное обеспечение зависит от аппаратных средств. Без железа ПО не существует.
- Электричество — да, для работы оборудования нужна электроэнергия, без нее оно бесполезно. Я работал над одним проектом с Raspberry Pi. У заказчика постоянно возникали проблемы с выключением устройства в случайные моменты времени. После нескольких дней исследований мы наконец-то выяснили, в чем дело. Он использовал не тот блок питания, который был в комплекте. Из-за этого устройство выключалось в произвольное время.
Так что на самом деле нужно исходить из того, что во всем есть ошибки. Именно поэтому опытные разработчики никогда не доверяют своему коду, если он успешно запускается с первой попытки. Даже если QA-инженер сообщает об ошибке, предположите, что в тикете есть свой «баг», и проверьте все.
8) Неопределенность станет вашим токсичным другом
На этой работе вы будете чувствовать неопределенность почти все время.
Я уже объяснял пример со сроками разработки выше. Это лишь один пример, когда вы чувствуете неопределенность. Вы стараетесь изо всех сил, но все равно не уверены на 100%, что сможете закончить работу в отведенное время.
Кроме этого, существует бесчисленное множество других неопределенных вещей. Вот несколько примеров:
- Внедрение в проект того, с чем вы никогда не работали, например, сторонних API — как вы собираетесь реализовать то, с чем не знакомы.
- Переход на новый проект с новыми технологиями — вы будете думать о том, как эффективно и продуктивно работать с тем, что вам необходимо освоить.
- Переход в новую компанию — вы не уверены в том, что сможете освоиться и найти общий язык с новыми людьми.
- Сообщение об ошибке в день, когда вам нужно закончить работу, — вы боитесь, что сорвете сроки.
- Гарантия занятости — экономические ситуации, пандемии, конфликты и другие факторы сильно влияют на эту отрасль, что приводит к увольнениям.
- Развитие технологий — вы никогда не уверены, что завтра вас заменят какие-то новые технологии, например искусственный интеллект.
Хорошая сторона неопределенности заключается в том, что она заставляет вас быть лучшим программистом. Она требует совершенствования и обучения, если вы хотите оставаться в игре.
9) Отключиться от работы будет практически невозможно
Время от времени я ловлю себя на том, что думаю о своей работе, проблемах и ошибках. Или о том, что я должен сделать завтра, хотя я должен расслабиться и отдохнуть.
Иногда холодная вода в душе пробуждает меня от мыслей о том, как я собираюсь исправить неприятный баг, над которым работал вчера. У меня было бесчисленное количество споров с моей девушкой о том, почему я сижу в Slack, когда мы находимся на пляже.
Поэтому я открыто признаю, что мне трудно отключаться от работы.
Особенно трудно отключиться, когда работаешь дома. Если ноутбук включен, вы всегда можете проверить электронную почту или сообщения в Slack.
Поэтому, чтобы избежать всего этого:
- Я выключаю ноутбук после того, как закончил работу.
- Ставлю на мобильном телефоне «тихий час» для рабочих писем.
- Я приостанавливаю уведомления Slack после рабочего дня. Я отключаю их в выходные дни.
- Когда мой разум попадает в петлю «думать о работе», я стараюсь сразу же ее прервать. Я напоминаю себе, что отдых и расслабление очень важны для продуктивной работы.
- После работы я совершаю длительные прогулки. В некоторые дни я занимаюсь спортом, например, паделем или футболом.
- Я стараюсь как можно больше общаться с людьми, избегаю экранного времени после работы.
И все же, несмотря на все эти ежедневные действия, я часто в этом терплю неудачу.
10) Вы получите больше пользы от хороших сотф-скилов, чем от хороших технических навыков
Технические навыки — это те, которые вы можете легко освоить. С помощью различных проектов можно понять тот или иной язык программирования. Можно изучить его синтаксис, плюсы и минусы. Это просто вопрос практики.
С другой стороны, софт-скилы гораздо сложнее совершенствовать. Для их совершенствования требуется много душевных сил. Вы должны делать то, что вам не по душе.
Нужно ставить себя в ситуации, в которых можно улучшить или отработать те или иные софт-скилы.
Например, общение — один из тех «мягких» навыков, о которых постоянно говорят. Допустим, вы не умеете выступать на публике. Вы должны заставлять себя находиться в ситуациях, в которых вы можете потренироваться в публичных выступлениях.
Очень трудно намеренно ставить себя в ситуации, в которых, как вы знаете, вы будете плохо выступать. Ваш разум сделает все, чтобы избежать таких ситуаций. Он будет придумывать сотни оправданий, и от этого легко отказаться.
Помимо общения, существуют и другие софт-скилы:
- работа в команде
- умение учиться
- организация/тайм-менеджмент
- эмоциональный интеллект/эмпатия
- умение находить подход
- настойчивость/терпение
- уверенность в себе
Я встречал много людей, которые хорошо владеют техническими навыками, но с которыми ужасно работать.
Например, один коллега часто обращался ко мне за помощью. Пару раз я ему помог. Потом я увидел, что после того, как мы устранили его проблемы, он вернулся ко мне и обвинил меня в том, что я испортил другие вещи в проекте. Тогда мне пришлось провести с ним больше времени, исправляя то, о чем я даже не подозревал. А поскольку он обвинял меня в такой дурной работе, я перестал ему помогать. Я сказал, что у меня много дел, и я смогу помочь ему только завтра.
Другой пример: я был новичком в проекте. Коллега (назовем его Джордж) был назначен помогать мне во всем, в чем я нуждался. Я настроил проект практически самостоятельно, но при попытке запустить проект возникла одна ошибка. Я обратился за помощью к Джорджу. Он потратил на решение проблемы в общей сложности около 2 минут и сказал, что не знает решения. Я все равно поблагодарил его, попытался решить ошибку самостоятельно, но в итоге добился успеха с помощью коллеги Майкла. На ежедневной планерке Джордж сказал, что весь день провел, поддерживая меня. После этого я никогда не обращался к нему за помощью.
Еще один пример: был один коллега, который был главным человеком в проекте. Тем не менее, вся команда его ненавидела (другие разработчики, менеджеры проектов, QA, дизайнеры и т.д.). Он был хорошим инженером-программистом, но настоящим придурком. Крайне грубый в общении со всеми. Он никогда не хотел признавать свою неправоту или принимать конструктивную критику своего кода. Руководство терпело его, поскольку он всегда был самым громким в комнате. Когда он наконец уволился, вся команда праздновала это событие.
Обладая хорошими софт-скилами, вы будете больше нравиться людям, и у вас будет больше шансов получить повышение или продвижение по службе. Если вы технически одарены, но с вами трудно работать, ваши шансы несколько снижаются.
Кроме того, при хороших «мягких» навыках люди, знающие вас, будут распространять добрые слова даже за вашей спиной. Они могут рекомендовать вас на работу, даже не подозревая об этом.
Заключение
Разработка программного обеспечения — это не работа мечты.
Работа в области разработки программного обеспечения часто подразумевает длительный рабочий день. Большую часть времени вы прикованы к экрану компьютера, а баланс между работой и личной жизнью практически отсутствует.
Работа требует присутствия в Интернете, иногда даже в нерабочее время. Это часто приводит к стрессу и нехватке личного времени.
Кроме того, удовлетворению от работы часто мешают утомительные задачи. В зависимости от ситуации перспективы карьерного роста ограничены. Кроме того, при удаленной работе существует потенциальная изоляция. И всегда существует угроза потери работы в связи с быстро развивающимися технологиями.
Но есть и положительные моменты.
Разработка программного обеспечения способствует постоянным инновациям. Инженеры-программисты могут создавать привлекательные приложения и решать интересные задачи.
Глобальный спрос на программные решения в различных отраслях очень велик. Это означает, что всегда есть спрос на хороших инженеров-программистов. Карьера разработчика программного обеспечения обеспечивает гибкость благодаря возможности удаленной работы.
Это одно большое счастье — работать из любого места. Гибкость позволяет спать по утрам без будильника. Вы можете работать из дома в удобной пижаме. Кроме того, вы не тратите свое драгоценное время и деньги на поездки на работу.