Мой путь в инфраструктурщики началася очень просто — CTO сказал: “сделай деплоймент, и не забудь всю инфраструктуру сохранить в коде, вот тебе пример Cloudformation шаблона, вперед”. Если CI/CD я сделал вообще просто (мы начали с такого проекта как CodeShip и Elastic Beanstalk), то с Cloudformation шло нереально туго. Я долго не мог врубиться какие значения куда подставлять и как вообще все эти ресурсы использовать и пытался решить проблему старым добрым университетским методом “подправь козу и сдавай”.

В Украине есть множество мелких контор, студий, которые делают всякие небольшие проекты для заграничного заказчика. Довольно распространены расклады, когда к студии приходит заказ, а свободного ресурса у нее нет. Для этого есть всевозможные фейсбук-группы для работорговли и обмена гребцами, там пасутся проджект менеджеры и сейлзы и торгуют “есть реакт дев по 25$ час”, “нужен iOS разраб”, короче базар. В руки вам скорее всего попадет пожухший проект, уже разработанный другими аутсорсерами, но по какой-то причине, требующий допила.

В 2007 году, когда я начал работать программистом за деньги, самым популярным мессенджером (по крайней мере, у нас) был qip/ICQ. Skype в то время еще принадлежал эстонцам, и делал p2p-соединения для звонков и чатов, история хранилась локально, не было центральных серверов и госдеп/кгб не читал переписку. По неизвестной мне причине, в компании скайп был запрещен к использованию IT-отделом для звонков. VoIP трафик был дорогой или что? Впрочем, на запрет все плевали, и общались по скайпу, особенно те, у кого не было стационарного цискофона.

Думаю многие в курсе о “джедайской технике пустого инбокса” Максима Дорофеева. Коснусь сейчас только одного аспекта техники — а именно собственно пустого инбокса в смысле “входящих” в почте. Когда я работал менеджером в NetCracker, то множество коммуникации проводилось в почте. Рабочие обсуждения, письма от коллег со старых проектов, которые приходят потому что ты до сих пор остался в рассылке, резюмешечки от HR, хлам от джиры и дженкинса, целая прорва информации приезжала каждое утро.

Часто повторяющаяся мысль во многих книгах и материалах о продуктивности: “Записывайте все свои идеи”. Обосновывается примерно так — мозг думает мысль пока её не реализовал, а чтобы реализовать — достаточно записать. Тогда мозг решит что мысль реализована, не нужна и выгрузит её из рабочей памяти. Сюда же относится и идея о том, что рассказав кому-то о том, что планируешь сделать, ты уже как бы делаешь, и дальше уже нет такой мотивации действительно что-то делать.

Самый лучший способ донести свою идею людям — это убедить их, что на этом можно зарабатывать/экономить деньги. Почему отлично заходят всякие опенсорс решения? Потому что авторы или developer advocates компаний убеждают всех вокруг, что их продукт сделает жизнь проще (== позволит заработать больше). Уже многие годы я так или иначе соприкасаюсь с около-экологическо-зоозащитной темой. Почему, например, плохо распространяется вегетарианство и борьба с промышленным животноводством? По одной причине — сейчас выгодно производить мясо и продавать его.

Пару дней назад проходил собес на девопс-чего-то там позицию в лидер рынка. Надо поддерживать себя в форме, все дела. Перед собесом рекрутер выдала мне ексель файл с сотней технологий по каждой из которых нужно было поставить себе оценку. После этого интервьюер задавал мне вопросы по этому списочку и проставлял уже свою оценку. Такого типа собесы распространены в больших компаниях, где процесс найма пытаются сделать максимально формализованным, поэтому я не удивился и спокойно реагировал на вопросы вроде “настраивали ли вы DHCP”, и “что такое BGP, vxlan?

Наверняка вы видели в ванильных пабликах цитату “Великие умы обсуждают идеи, средние умы обсуждают события, мелкие умы обсуждают людей”. Если посмотреть на всяких блоггеров и генераторов контента в инфополе, то можно обратить внимание, что все их сообщения/посты/книги так или иначе сконцентрированы вокруг малого количества ключевых идей/концепций, и, если читать автора достаточно долго, то начинаешь замечать самоповторы. Например, ребята из Basecamp (DHH и Jason Fried) пишут об спокойной работе и здоровом work/life balance, асинхронных коммуникациях, негативном влиянии венчурных капиталистов на бизенсы.

Всем конфы хороши, да не только. Немного поноем. Если конфа околотехническая то скорее всего значимая часть докладчиков будет иностранцами и соответственно доклады будут на английском. Доклады на английском мне не очень нравятся, потому что мозг теряет часть информации во время конвертации. И если воспринимать речь/читать без перевода в голове я уже насобачился, то часть незнакомых оборотов или сжеванные произношением фразы (особенно если докладчик — нативный спікер) парсить получается не всегда и как ни крути невозможно получить так сказать full experience.

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

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

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

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

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

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

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