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