🍀 Когда ты находишься на пределе своих возможностей, то наконец-то знакомишься с собой настоящим. Точки роста программиста случаются через боль, пот и слезы, из-за суток труда - без сна и отдыха...
Мне искренне хочется, чтобы вместо наивного настроя "как быстро и без знаний много заработать в IT" вы открывали статьи этой рубрики с трепетом и предвкушением, как от остросюжетного романа.
Понимаю - еще рано для подобного рефлекса, но так ведь я еще даже не начал рассказывать самые интересные истории...
Сегодня, мои добрые друзья, я вновь поведаю вам о невидимой для внешнего наблюдателя стороне IT, о которой вам не расскажут HR, авторы книг или курсов по программированию.
Итак, сегодня поговорим о выживании и пределе выносливости... ☕️
08.03.2025, Суббота, 22:00. Рубрика: Будни сеньора. Время на чтение: 5 мин.
🔸 Часть 1. Почему программисты упахиваются вусмерть
Чтобы сразу лишить вас иллюзий по поводу work-life balance в IT-шечке и ввести вас в контекст того, что там на самом деле творится, позвольте начать с короткой отсылке к известной книге «Кровь, пот и пиксели: обратная сторона разработки видеоигр» за авторством Джейсона Шрейера (2017).
С изданием в России связана дичайшая история с запоротым переводом от Эксмо (все подробности можно прочитать здесь), но в сети доступна версия книги с пометкой "Новый/правильный перевод".
Позже обязательно сделаю её полный разбор, поскольку это моя настольная книга - обращаюсь к ней раз в год за новой волной мотивации.
Пока же максимально кратко резюмирую для вас её суть - в разработке больших программных продуктов (не только видеоигр) в ключевые моменты (перед деадлайнами) принято сильно перерабатывать, буквально жертвовать собой, ради проекта.
Для таких затяжных авралов даже есть специальный термин - кранч (когда вся команда вкладывает столько человеко-часов и энергии, сколько нужно для завершения проекта в срок и его внедрения).
Приходя на должность "разраба" вы автоматически подписываетесь кровью на неформальную повинность в виде будущей жесткой переработки в ключевые моменты разработки системы.
Дело в нескольких факторах, но кратко - трудность с прогнозированием времени и сложностью разработки.
Истоки этой проблемы даже сформулированы в монументальной книге 1986 года "Серебряной пули нет" Фредерика Брукса (которую представьте себе, я тоже читал, так что имею право ссылаться на неё). Среди прочих сакраментальных высказываний там есть утверждение, что сложность разработки программного обеспечения является неотъемлемой частью этого процесса.
Кстати именно поэтому я не верю, что AI заменит труд программиста полностью - писать код он может (я лично проверял ChatGPT, поручая ему свои рабочие подзадачи), но спроектировать и построить систему целиком - пока нет.
Если интересно, мы детальнее побеседуем эти темы позже, а пока просто примите, как факт, что легко и быстро в IT не будет.
🔸 Часть 2. Что такое "внедрение проекта"?
Блог читают и не айтишники, а также специалисты из других сфер IT, поэтому поясню как происходит "внедрение" с точки зрения серверного программиста в предметной области "Логистика".
Я не могу раскрывать детали своей работы, поскольку у нас в компании внедрена комплаенс-функция, в рамках которой в том числе мониторится: не разглашают ли сотрудники коммерческую тайну или другие аспекты своих трудовых обязанностей (вполне возможно, мой блог тоже "на карандаше").
Однако укрупненно это выглядит так - есть Система, с которой взаимодействуют десяток тысяч пользователей, через которую проходит большой поток данных о различных событиях в реале, множество бизнес и логистических процессов завязано на корректности выдаваемых Системой информации.
Она имеет различные интерфейсы для широкого класса устройств и оборудования. Копии такой системы работают более чем в десяти крупных логистических центрах по всех России.
Система непрерывно дорабатывается, но каждое изменение сначала тестируется на отдельной тестовой площадке. И момент переноса с тестовой на рабочую площадку и называется "внедрением".
Это согласованный час Х (иногда это минута, иногда целый день, в зависимости от масштаба изменений), когда происходит замена исполняемого кода Системы - серверных, клиентских (frontend и backend) скриптов и алгоритмов, админских конфигураций и даже аппаратного оборудования.
Чаще всего стараются сделать обновление "бесшовным", как минимум для конечных клиентов. Но порой требуется небольшая остановка технических и организационных процессов.
Трудности подстерегают внедренцев по всей широте затронутых частей Системы - от логических багов и физических сбоев, упущенных неочевидных деталей, до противоречивых приказов и инструкций или шквала жалоб из-за непринятия пользователями "новых правил игры".
Но самое сложное - это скорость реакции, с которой предстоит анализировать и устранять ошибки. Вдумайтесь только, что в половине случаев ожидаемая от серверных программистов (в нашей компании) скорость исправления критичной ошибки - менее 1 минуты (понять что не так, открыть исходник этого модуля, найти строчку, исправить, проверить и выставить в прод). Вот вам просто для наглядности парочка ситуаций, где я отработал с положенной скоростью реакции.
Одним словом, внедрение - это большой стресс.
🔸 Часть 3. Масштаб разрушений
Надо понимать, что внедрение - это вовсе не редкое событие раз в год. Внедрения исправленного или нового кода происходят постоянно, почти ежедневно, но разница в их масштабе. Удобнее представить себе масштабность изменений в виде фрактала: где небольшое однострочное исправление ведет к исправлению функции, которая ведет к исправлению модуля, который может привести к исправлению и выставлению отдельной функциональности, которая тянет за собой изменение в бизнес процессе, а множество таких изменений постепенно складываются во внедрение Системы на целом промышленном объекте.
Так что в своей работе я сталкиваюсь с микро-внедрениями (когда моя рука касается "прода") каждый день. Пару раз в месяц выставляются решенные задачи. Раз в квартал новая функциональность. Пару раз в год - масштабное изменение Системы. И, наконец, раз в 2 года - внедрение Системы на новой промышленной площадке с нуля.
Именно такое эпохальное по шкале Рихтера внедрение происходило в октябре 2024. Достаточно упомянуть, что за 7 лет работы это всего второе внедрение такого масштаба, в котором я участвую и всего четвертое-пятое для компании за этот период. Огромное такое брокколи - с дом...
Подготовка длилась 2 года, начиная от первых ФТ, проектов ТЗ, сбора данных. Обычно на этом этапе программисты не участвуют, только если они не архитекторы или тимлиды. За год до внедрения даже я съездил "в поля", на объект, что бывает очень редко - посмотреть на физическое воплощение той бизнес-логики, которую придется "закодить".
Неспешно происходила разработка, тестирование и внутренняя приемка разных частей Системы. Но так всегда бывает, что вся эта теоретизированная работа начинает сильно расходиться с реальностью. Это нормально.
И вот за месяц до часа Х начинается приемка модулей вышестоящим начальством с обоих сторон, ПСИ (приёмо-сдаточные испытания), обучение, установка программного обеспечения и оборудования, а также интеграция уже существующих систем и взаимодействие команд (людей) с друх сторон.
С этого момента и начинается стресс и кавардак, который доходит до апогея к deadline (не зря же его так называют - хоть умри, но сделай к этой дате) - дню внедрения:
- отлаженные по отдельности части системы при сборке вместе не стыкуются между собой;
- разработанные решения не вписываются по времени, объему операций в реальный производственный процесс;
- нагрузка потоков данных оказывается далека от прогнозируемой;
- всплывают нормативные акты, требования и законы, которые вдруг нужно выполнить и которые почему-то раньше не попали в ФТ;
- и прочее, прочее, прочее.
Если до дня внедрения было просто сложно, то с дня внедрения и 3 недели после некогда даже спать, есть приходится у компа, а все прочие дела отложить в долгий ящик.
Абсолютно все проблемы, которые возникают на твоём участке ответственности должны быть решены и быстро, иначе ты подставляешь других людей, тормозишь процессы, клиенты терпят убытки, а высокое начальство оценивающе смотрит тебе прямо в душу...
И нельзя просто сослаться на болезнь, отпроситься по личному делу, сказать, что не включается мозг в 3 часа ночи - ты просто должен выдавать максимум без остановки, пока не иссякнет поток писем, сообщений об ошибках, запросов на анализ ситуации и пр.
День внедрения был объявлен 24-часовой сменой для всей команды внедрения (около 25 человек). Ты конечно мог спать, забирать детей из сада, принимать пищу или тихо плакать в ванной комнате, но в пределах 15 минут должен быть браться за решение поставленной перед тобой задачи.
Затем каждый третий день в течении двух недель каждый из программистов получал ночную смену - с 21 часа до 9 утра. И это после отработанного рабочего дня! Утром следующего тебя не трогали до обеда, но потом сообщения начинали стучаться в мессенджеры и почту.
Между этими ночами были и дневные смены - ты был дежурным с 9 утра до 21 часа и должен был первым встречать запрос, анализировать, решать или перепасовывать другим.
Особенно запомнись 34 часа в середине внедрения, которые я отработал всего с несколькими перерывами по 1-2 часа. Включая ночь, в которую пришлось непрерывно программировать с аналитиком на связи, то есть онлайн - с 23 часов до 6:30 утра...
Так что? Вы еще хотите попасть в IT, стать программистом? 😈
🍏 Меня зовут Андрей, я - Senior SQL Developer. Более 20 лет я смотрю на мир через призму SQL-запросов и теперь хочу поделиться этим видением с Вами.
Мира и добра Вам! До встречи в следующем выпуске!
Выпуск №18, Санкт-Петербург, дата написания 03-08.03.2025