Прошлые два дня посвятил посещению #DevOpsDaysKyiv. Идти решил совершенно спонтанно, увидел пост в канале https://t.me/devopsengineer, там был скидос 20%. Хотя темы докладов на первый взгляд меня не зацепили (как я позже узнал, основной поток всегда идет о каких-то околокультурных вещах, не о технике), я подумал что неплохо будет узнать чем люди вообще занимаются сейчас и пообщаться с сообществом. К своему стыду, за всю свою жизнь я был всего на одной технической конференции — JavaDay 2014.

Вдобавок к тому, что вместо полемики в комментах стоит писать свои материалы, я бы еще хотел коснуться важной темы — сути комментариев и дискуссий в нашей, пост-советской части интернетов. По неизвестной мне причине (вероятно, из-за среды, но это не точно), большинство людей и комментаторов на наших просторах токсичны и агрессивны. Редко какое обсуждение обходится без прямых оскорблений и ad hominem, без позиции в стиле “я Д’Артаньян”, без пассивной агрессии, троллинга, сортирного юмора и других хорошо знакомых всем штук.

Я большой любитель пообщаться. IRL получается не всегда, поэтому время от времени приходится сублимировать в форумы и прочие коменты. За полтора десятка лет я суммарно по всем форумам (кпишные usenet-конференции, разного рода тематические phpBB форумы, доу, хабр, vc и тд) напостил наверное тысяч 20 сообщений, а то и больше. Дискутировать охота на интересные мне темы, но практически всегда мое мнение идет вразрез с мнением автора/большинства. Завязывается небольшой бокс по переписке, тратится время на поиск аргументов, на цитирование, попытки пробить брешь в стенах защиты оппонента и так далее.

Давно не было нытья о рекрутерах! Все знают что на рынке есть рекрутинговые агенства. Типа мы вам подберем лучшего кандидата, овер 9000 лет экспертизы и все такое. Такие конторы конечно же очень даже нужны всяким стартапам или компаниям, которые только заходят на рынок, вообще не имеют команды, или пока что не обзавелись внутренним рекрутером, а так же полезны для найма C-level людей и закрытия всяких экзотических вакансий. Но вот что меня всегда забавляло — так это рекрутеры из агенств, которые перепродают тебе вакансию условного Люксофта или другого крупного игрока.

Хорошо работает только планирование рутинных задач. Типа “добавить отчет”. Если мы уже делали похожие отчеты, то примерно знаем, сколько на них нужно будет потратить времени, накидываем ±пару дней и спокойно едем. А вот всякие околоисследовательские штуки, или что-то неизвестное можно только ограничивать временем вроде “давайте попробуем потратить 5 дней на исследование а дальше посмотрим”. Ну это тоже такое себе планирование, потому что может оказаться что 5 дней мало, дальше берутся еще 5, потом еще, потом еще и вот уже два месяца ушло и только теперь стало ясно куда можно копать дальше.

Самая большая проблема разработки — сроки. Бизнес любит ставить сроки (а как работать-то, без них?), разработчики не любят называть сроки, менеджеры любят занижать сроки, а в итоге они всегда продалбываются. В чем я точно уверен — так это в том, что сроки на длинном временном промежутке планирования (год, а то и меньше) 100% будут сорваны. Даже если не изменятся требования (а они изменятся), не будет смены приоритетов (а они будут), не будет меняться состав команды (а люди будут приходить и уходить), и будут заложены буферы (работа занимает столько времени, сколько на нее отводится).

Крайне распространённая манипуляция — ”нужно на вчера”. “Нам нужно срочно закрыть вакансию, не могли бы вы выйти пораньше?”, “Два дня на подумать”, “Багу срочно нужно пофиксить”, “Фичу срочно надо выкатывать”, “Никто, кроме тебя это не сможет сделать” и так далее. Так вот, ничего не случится, если человек выйдет на две недели позже. Вы и так уже ищете два месяца подходящего, не подождете еще две недели? Допустим, я ищу работу. Последнее, что стоит делать — соглашаться на первое предложение и отметать будущие возможные варианты, даже не рассмотрев их.

Оставлять гребцов в лодке одних, наедине с океаном нереализованных требований опасно (пойдут не туда), поэтому над разработчиками всегда ставят надсмотрщика-менеджера. Когда начинается жопа, все горит и ломается, то, как правило, проблему может исправить только вдумчивая и длительная работа соответствующих специалистов. Однако если у инженера есть возможность прямо влиять на ситуацию — разбирать ошибки, читать стековерфлоу и пробовать-пробовать-пробовать починить, или есть в голове примерный план переписывания совсем уже прогнившего участка трубы, то у менеджера такой роскоши нет.

Главный движитель карьерного роста — готовность бесстрашно брать на себя ответственность. Когда долгое время работаешь простым разработчиком то как-то привыкаешь что все решения принимают за тебя — как делать продукт, какие технологии или стек выбирать, как развивать команду, куда расти тебе лично (менеджеру, ему же точно виднее). В этом мирке очень ценятся люди, которые не очкуют встать и сказать — ”вот это сделаем так и так, я готов взяться/возглавить”. Когда я только начинал менеджерить и беспокоился о решениях, которые нужно было принимать, то мой босс все время твердил — ”лучше предложить хоть какой-то план, даже если он не очень хорош и взять на себя ответственность, нежели вообще ничего не делать”.

Вот уже два года как я работаю удаленно. В интернетах полно материалов на тему почему удаленная работа хороша, или почему хорош фриланс (это разные вещи, если что), как начать и вот это все, фокусируясь на достоинствах удаленки. Спустя пару лет могу подтвердить, да, все действительно так. Не врут. Зачем же ходить в офис? Существенным недостатком удалённой работы из дому для меня является отсутствие социализации. Человек — животное социальное, и видеть и разговаривать с другими людьми лично, а не через интернет — обязательно.

Компании часто добавляют в договора пункты о неразглашении зарплат а руководство с HRами еще и грозит анальными карами и санкциями за нарушение этого пункта. В конторе где я раньше работал один из руководителей прямо заявлял — за разглашение зп увольняем сразу. О прецедентах никто не слышал, но все боялись. Что интересно, в советские времена такого не было — все знали зарплаты друг друга. Социализм во все поля! Приходишь в бухгалтерию, расписываешься в ведомости и там видишь зарплаты всех остальных.

В больших корпорациях часто есть множество офисов, рассосредоточеных по всему миру. В конторе, где я раньше работал, было 2 офиса в Украине, 5+ офисов в РФ и бесчисленное количество команд, которые сидели у заказчика по всем странам и часовым поясам мира. Из-за большого количества проектов, практически всегда команда собиралась из разных офисов. Очень редко было такое, что все сидели в одной комнате. Но, что интересно, не так редка была ситуация, когда человек был единственным, кто работал на проекте из его окружающих.

Уже несколько лет подряд я ретроспективно оцениваю решения и поступки которые совершал в прошлом году. И каждый раз думаю — “черт, как я мог творить такую дичь? зачем я в это вписывался? зачем соглашался? почему не приложил больше усилий для?”. Что характерно, история повторяется каждый год. То есть вроде бы и думаешь — “ну все, в этот раз такой шляпы не будет”, а нет, проходит год и опять понимаешь что делал дичь.

В любой системе, которая имеет дело с реальным миром так или иначе присутствуют куча условий и ветвлений. Например, нам приходят заказы. От разных контрагентов. Но контрагентов есть множество видов, и заказ каждого отдельного вида обрабатывается по отдельной логике. Разработчик, задолбавшись реализовывать n-дцатое условие в коде, рано или поздно решает написать некую конфигурацию бизнес-правил обработки этих самых заказов, дать в руки бизнес-людям конфигуратор и свалить в закат. Вроде все просто, реализовал десяток блочков, как-то их собрал в кучку под каждый отдельный случай и все работает, можно пить смузи.

Обычно у разработчиков не возникает проблем с решением задач. Поисковики, стековерфлоу, куча мануалов, в принципе все типовые задачи уже давным-давно решены, а нетиповые — так их делают опытные люди. За всю карьеру полностью прочувствовать свою беспомощность и неспособность справиться с задачей меня угораздило только один раз (ну и еще было много других мелких случаев, когда просто задача давалась тяжело, но удавалось как-то разрулить). Дело было в 2009-2010 году — работал я значит в корпорации, подпиливал свой маленький (тогда) продукт, в ус не дул.

Почти всю свою карьеру я так или иначе занят в продуктовой разработке. Помимо продуктов я делал собственно демо-проекты и разнообразные прототипы других продуктов. На старой работе у нас был такой термин “продуктизация”. Это когда бралось решение, сделанное кастомного под определенного заказчика, творчески переосмыслялось и впихивалось в продукт. Идея была в том, что эта кастомная функциональность могла бы пригодиться кому-нибудь в будущем. Одной из моих задач, как технического руководителя одного из продуктов, было отбиваться от запросов на такие всякие разные продуктизации.