За 8 месяцев в Microsoft я научился этому

Моя стажировка в Microsoft Windows Azure началась ровно два года назад, сразу после колледжа, и проходила она в той же команде, с которой я работал и последние восемь месяцев.

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

Не могу сказать, чтобы я был несчастлив, и не хочу ни на что жаловаться… но в колледже об этих вещах меня никто не предупреждал.

Итак, поехали.

• Не надейтесь найти в корпорации документацию. Исходя из того, что мне довелось видеть — все знания в компании передаются в основном посредством разговоров и мастер-классов. Часть доступной информации передается по электронной почте и вообще нигде не сохраняется. В остальном мире сейчас так не принято — ведь если кого-то вдруг нечаянно собьет автобус, то никто другой не сможет легко взять и продолжить его работу (например, сесть и сразу писать дальше код). И тут это считается нормой. Если бы у меня была компания, то я бы предпочел иметь вики на тысячи страниц.
• Важно не то, что ты сделал — важно то, что ты продал. Можно днями улучшать свой код и править чужие ошибки, но пока это не оказывает никакого влияния на продажи и результат усилий невозможно продать — ваша работа практически ничего не значит. Никого не интересуют ваши правки кода в погоне за его чистотой или стилистическим единством; никого не интересует и решение проблем с архитектурой. На вас даже могут обидеться, если вы будете заниматься подобным. Когда я был студентом, мне не это рассказывали.
• Не всем есть дело до программирования. Вы не всегда будете работать с теми, кто нежно любит разработку софта. У большинства людей здесь есть в жизни что-то еще (семья, дети), поэтому стремление написать чистый код чаще всего не входит в их планы. И это нормально. Я научился не ждать энтузиазма от всех и каждого.
• 2-3 часа чистого кодинга в день — это замечательная цифра. До того, как я попал на свою работу, я программировал 8-10 часов каждый день, сидя за своими проектами. А в новом окружении у меня едва удается писать код 2 часа кряду. Большую часть своего времени я провожу в попытках понять, как работает чужой некомментированный/недокументированный код, занимаюсь отладкой странного поведения программ и посещаю ежедневные собрания. Все сказанное касается не только меня, поэтому случается, что проходят дни без единого коммита во всей команде. И это тоже нормально.
• Ничего не делать для других взамен — это нормально. В своей организации я не встретил ни одного блоггера или разработчика открытого ПО, который бы посвящал часть своего времени любой «отплатой» коммьюнити. Гуглить ответы на Stack Overflow — это с радостью, но свой ответ на вопрос там никто никогда не напишет. Я их понимаю.
• Здесь не слишком осведомлены о том, что происходит во внешнем мире. Думаю, все вы каждый день читаете различные новости IT-тематики в блогах, на Reddit или Hacker News. Здесь это не принято. Я был удивлен, когда узнал, что никто из команды WIndows Azure никогда не слышал про Heroku или Rackspace — а ведь это их прямые конкуренты. Это приемлемо, не всем же про это стоит знать. (Тут действительно поразительное сходство с Apple, если верить книге Адама Лашински «Inside Apple» — прим. переводчика)
• Суть в том, чтобы делалось дело. Если менеджер просит вас о кнопке, которая будет делать то-то и это, то никого не интересует, чего вы там наворотите. Когда запрошенная функция начинает работать, можно считать, что задача выполнена — все остальное можно будет поправить потом. Хотя, честно говоря, сам-то я с этим обещанным «потом» никогда так и не сталкивался. В колледже мне говорили, что качество кода так же важно, как и сам результат его работы. Тут оказалось, что это не так.
• Копипаст кода — это нормально. Если кто-то на Github застукает вас за подобным приемом, готовьтесь к расправе в темной подворотне. Тут же я не раз встречал исходники, которые просто копипастились из проекта в проект. Поскольку свое дело они делали (об этом — ниже), никого не интересовало то, что код абсолютно неподдерживаемый.
• Ради скорости дела можно обойтись и без code review. Это один из обычаев нашей команды — если ты связался с чужим кодом, то ты должен отправить code review. Обычно же этим никто не занимается, и можно прождать уйму времени, прежде чем кто-то после десятого письма вам ответит.
• Последние версии ПО, ага, как же. Далеко не всем нравятся последние версии. 90% моих коллег используют старые версии Office, Windows, Visual Studio и .NET Framework. Есть суеверие, что новые версии напрочь ломают устоявшийся рабочий процесс. Наверное, им руководствуются те, кто до сих пор запускает все свои приложения на Java 1.3 — 1.5. Так я отучился ждать использование последних версий ПО в проектах.
• Ваша специализация не имеет значения. Студентов нанимают тысячами и случайно распихивают по командам (которые вы не сможете сменить еще полтора года). Неважно, развлекались ли вы с MongoDB, разрабатывали приложения под iOS, коммитили в Apache, дизайнили интерфейсы или «бустрапили» свой личный стартап. Вас наняли, чтобы вы сделали то, что вам скажут. Я не ожидал подобного. Здесь слишком сложно найти то место, где можно было бы заниматься тем, что любишь.
• И в заключение. Вы работаете на своего менеджера и на его чек. Вот об этом мне точно никто раньше не говорил.