Впрочем, обо всем по порядку.
Бытует мнение, что в больших компания все функционирует как швейцарский часовой механизм. На каждом месте есть выделенный сотрудник, система оповещений и групповая работа настроены безупречно, на любой инцидент поднимается команда подготовленных спецов, которые мигом реагируют на происшествие.
Но в идеале так должно быть только в промышленных компаниях, где есть инженеры и рабочие, а не разработчики. Компании, занимающиеся программной разработкой, — это «отдельная песня».
В 2013 году сотрудник Microsoft по имени Ахмет (Ahmet Alp Balkan) опубликовал пост в своем аккаунте, в котором поделился впечатлениями о команде разработчиков Microsoft Azure. Окончив колледж, он присоединился к ней в качестве стажера и проработал в Microsoft до конца 2016 года. Позднее он ушел в Google Cloud, где трудился до 2021 года.
Впечатления Ахмета Балкана относятся к первым восьми месяцам работы в команде разработчиков Microsoft Azure. Его заметки отличаются живостью и оригинальностью, поэтому мы и предлагаем познакомиться с ними.
Не ждите готовой документации на код в корпорациях. Знания передаются внутри компании в основном через разговоры и закрепляются на практических занятиях. Отрывки кода могут отправляться по электронной почте, но никто не сохраняет их на постоянной основе. Поэтому ценность каждого сотрудника велика. В случае его ухода взять на себя его работу или продолжить написание его кода — часто неподъемная задача. Но в корпорации такое положение дел считают нормальным.
Ваша работа оценивается не по тому, что вы сделали, а как вы сумели «продать» свой код. Можно сутками улучшать написанный код, добиваться надежности в его работе, исправлять чужие ошибки… Но если менеджеры не видят от этого практической пользы для бизнеса, то ваши старания практически никто не замечает. Никто не оценит и не отблагодарит вас за исправление ошибок. Более того, если исправления были связаны только с оптимизацией кода, а не исправлением ошибки, то «заинтересованные» коллеги могут даже обидеться. Не надо лезть в чужие дела.
Далеко не все увлечены своей работой. В любом коллективе людей в основном волнуют совсем другие вопросы, например, их семья или дети. Написать лучший код для большинства коллег не более чем «яркая обертка от конфетки». Ждать энтузиазма от коллег в разработке бессмысленно.
Сколько времени надо заниматься написанием кода? Как показывает практика, достаточно двух-трех часов. Кодировать по 8—10 часов в день нет смысла. Более того, писать код непрерывно в течение двух часов подряд просто невозможно: основная часть времени уходит на изучение чужого кода. Требуется понять, как он работает, поскольку нет ни документации, ни сопроводительных комментариев. Часто приходится заниматься отладкой очень странно написанного кода, организуя личные встречи с разработчиком.
Никто не делится своими наработками через Open Source. Встретить такого блогера или разработчика в компании, которая ведет разработку коммерческого продукта, нереально. При этом все занимаются поисками разъяснений по коду в Stack Overflow, но никто не оставляет своих комментариев.
Что творится в отрасли программирования, мало кому интересно. Разработчики коммерческих продуктов не интересуются ежедневно, какие новости появились на Hacker News или где-то еще. Разработчики также не интересуются, что делают конкуренты. Этой задачей занимаются менеджеры.
7. При разработке постоянно возникает неразбериха. Когда руководитель группы просит добавить кнопку, то никого не волнует, если сделать это «левой ногой». Если функциональность достигнута, то никто не возражает, считая, что ошибки можно устранить позже. При обучении обычно учат писать «красивый» код, на практике этим мало кто занимается.
Кража чужого кода (копипаст) внутри корпорации считают нормальный явлением. Проблемы могут возникнуть только при краже чужого кода на стороне, за пределами компании. Но внутри компании можно копипастить код из других проектов, и никого не волнует, что лично вы можете даже не понимать особенности его работы.
Параллельную проверку кода обычно не делают. Это позволяет повысить скорость разработки. Даже если отправить запрос к коллегам с просьбой на проверку, этим никто не будет заниматься сразу. Откликов можно ждать бесконечно долго, пытаясь привлечь внимание — никто не занимается проверкой чужой работы.
Никто не пользуется новыми версиями программ. Почти 90% разработчиков Microsoft используют старые версии Office, Windows, Visual Studio и .NET Framework. Большинство не любят новые версии, им не нравятся их нововведения. Но есть и вполне «распространенное» объяснение этого факта: при переходе на новые версии программ приходится корректировать рабочие процессы. Ведь кто-то мог не сделать замены и может столкнуться с проблемами при открытии программ и файлов.
Ваше образование обычно не имеет никакого значения. Каждый год компания нанимает тысячи выпускников из колледжей и распределяет их по командам случайным образом. Перейти в другое подразделение нельзя как минимум на протяжении 1,5 лет. Поэтому неважно, что вы освоили или раньше создавали: нанимают ради выполнения конкретной прикладной задачи.
Если вы думаете, что работаете за зарплату, то ошибаетесь. Вы работаете ради премий и бонусов, которые получают менеджеры за выполненную вами работу. Все остальное вторично.
Наверное, в каждой компании есть свои особенности, но в целом по отрасли они одинаковые. И пожалуй, лучше понимать и использовать их, чем жить в розовых очках.