Самое (не-)приятное занятие в работе с людьми - объяснять и доказывать элементарные, на мой взгляд, вещи.

Список огромный, но самый излюбленный дискурс - High Availability (HA) против Disaster Recovery (DR). Люди, даже технически подкованные, часто путают или, что еще хуже, смешивают эти два понятия.

Есть простой пример "из жизни", который прекрасно дает понять контекст.
HA - это несколько двигателей у самолета.
DR - это что должно произойти, когда самолет падает или ударяется об землю.

Этот пост для Medium давно лежал у меня черновиках, но его пришлось заморозить, пока я не закончу работой над книгой.

Теперь, когда у меня появилось в разы больше свободного времени, я смог его закончить.

Этот опус для тех, кто не теряет связи с реальностью и понимает, что одними авсами и куберами сыт не будешь - в погоне за благосостоянием придется начать все больше и больше работать с людьми. В публикации вы найдете мой опыт и советы, которые, я надеюсь, помогут вам принять верное решение.

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

На предыдущем месте работы я считался individual contributor, такую "метку" присваивают специалистам, которые не занимаются менеджментом, а просто делают свою работу. В нидерландских компаниях работу менеджера в принципе пытаются нивелировать до минимума - толи из-за миллениалов, которые не научились в субординацию, толи из-за нелюбви к конформистской/конкуретной организации.

Как результат, мне приходилось идти на компромиссы со всеми подряд, но делать это приходилось крайне редко - никто не обладал такой же, как у меня, экспертизой в вопросах инфраструктуры и системной инженерии, а это в разы упрощало проталкивание своих идей. Чего нельзя было сказать о моих коллегах из разработки.

Как и в любой wannabe бирюзовой организации, у нас были смешанные команды из front и back разработки, где у каждого было видение через призму своей специализации. Думаю, вы сами прекрасно понимаете, как сложно таким договариваться.

Дела стали еще хуже, когда свежая кровь из только что нанятых коучей стала создавать так называемые "гильдии" (по аналогии со Spotify). Теперь, если ты фронтендер, тебе нужно было договариваться не только с бородатыми бекендерами, но и с особенными снежинками из своей гильдии, где каждый тащит свой подход ко всему - фреймворкам, платформам, coding conventions и прочим радостям промышленной разработки.

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

Итоговая картина получалась идиотская, но оно работало (да и до сих пор работает).

Быть единственным прошаренным амазонщиком в конторе было очень легко, а когда мои коллеги стали подтягиваться по знаниям, сложнее не стало - Well-Architected Framework един, и следуют ему все. Но вернуться в старое доброе лоно enterprise разработки после нескольких лет в ИТ-детсадике было радостно, хоть и очень непривычно в первое время.

Если спросить меня, с кем я больше всего хочу поработать, я однозначно назову имя Брендана Грегга.

Мало того, что Брендан автор Systems Performance, у него также имеются оригинальные исследования.

Например такое: https://youtu.be/tDacjrSCeq4

COUNTRY ROAD; TAKE ME HOME; TO THE PLACE; I BELONG

По иронии судьбы моих самых "сложных" stakeholder'ов зовут либо Себастьян, либо Кристоф.

От меня мало контента, но есть две новости:
1. Underpromise and overdeliver: моя книга вышла на 21 день раньше!
2. 4-ого июня можно будет увидеть мое карантинное лицо, рассказывающее основы основ одного маленького облачного провайдера. Всех буду рад видеть!

Меня все беспокоит одна дилемма.

С одной стороны "упрощение" в ИТ я готов приветствовать хотя бы за то, что оно в значительной мере ускоряет работу людей. Низкоуровневая инженерия - неблагодарный труд, который требует десятков лет подготовки - спросите хотя бы тех, кто занимается разработкой облачных систем. Для вас там все абстракциями обмазано, а ребята те самые абстракции на реальном железе поднимают.

То же самое касается рутинных инструментов для сериализации данных , всяческих оберток и прочей тоски, да хоть фреймворков для разработки приложений (и не только веб). Писать их с нуля - долго, сложно и, простите мне мой приступ снежинки, скучно.

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

Отобрать у системных инженеров живое железо, оставив им необходимые интерфейсы для автоматизации создания и управления средами - тоже хорошо и здорово.

Не мучай себя, не разбирайся с багами в сетевой карточке, не пиши свой обработчик файлов XML, пусть это за тебя сделают те, кто умнее тебя в стократ, пусть бизнес заплатит им за это - так элементарно дешевле! Все же отлично, правда?

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

Рынок по всему миру перегретый, большие (в сравнении с другими сферами труда) деньги можно заработать, пройдя 2-месячный интенсив - как тут мотивируешь людей учиться и думать, а не совершать одни и те же механические действия?

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

Что с этим делать - хер знает. Простите за рефлексию.

Я ожидал какой угодно реакции... Но точно не такой. х)

Очень крутой доклад о том, почему и как все (не) работает, и что с этим делать: https://www.youtube.com/watch?v=xA5U85LSk0M

Всем, кто хочет сдавать экзамены AWS, настоятельно рекомендую проходить Exam Readiness курсы, они бесплатные и позволяют оценить масштаб трагедии.

Регистрируем аккаунт и смотрим по этой ссылке: AWS training and certification

Пока готовился к одному из экзаменов, решил прослушать readiness и нарвался на брильянтовую классификацию "облачных" миграций, которая называется "6 Rs".
1. Retain - для очень сложных и болезненных приложений. Не трогаем, потом вернемся.
2. Re-host - так называемый lift-and-shift, тащим как есть, а там разберемся.
3. Refactor - он же метод transform. Миша, все по новой, все херня. Разрабатываем приложения с нуля уже в облаке.
4. Re-platform - lift-and-shift с модификациями.
5. Replace - вместо миграции заносим денег вендору (вместо своей Mongo покупаем DocumentDB).
6. Retire - оно тебе не нужно, сжечь и забыть.

Я повидал немало дерьма, так теперь знаю, к какой R оно относиться.

Тех же, кто еще только открывает для себя AWS, я приглашаю послушать мое выступление 4ого июня.

Фильм Дудя про талантливых русских ребят из долины я посмотрел не сразу. Понадобилось несколько постов в соцсетях, предлагающих девушкам поставить Tinder и сменить локацию на западное побережье, чтобы я был заинтригован и пошел тратить 3 часа в свой выходной.

Ну посмотрел и посмотрел. Фильм как фильм, Дудь как Дудь, предприниматели как предприниматели. Тема с курсовой в виде стартапа прикольная, что-то похожее (собрались группой и делаем продукт), было у меня на 3-ем курсе, когда мы осваивали MSF.

И вроде волна прошла, но есть люди, которых этот фильм нехило огорчил. На Хабре один из авторов жалуется, что такое творчество отобьет у молодых специалистов тягу к изобретательству и склонит к освоению PowerPoint, а не C. Штош.

Уберем из множества "вошедших в айти", прошедших интенсив и занявших должность junior frontend crud button ninja с зарплатой в 60 килорублей.

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

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

Что же касается тех, кто работает из интереса, то тут нечему удивляться - люди любят решать сложные инженерные задачи (какая реальная проблема при этом решается - дело второе). Есть люди, для которых R&D - сильнейший наркотик и величайшее благо (и это круто), но не нужно быть семи пядей во лбу, чтобы понимать, кто патрон этого самого R&D.

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

Зачем AWS спонсирует Rust? Затем, что от развития Rust зависит развитие Firecracker и многих других продуктов и решений, которые разрабатываются внутри AWS. Зачем JetBrains инициировал и развивает Kotlin? Откуда ж мне знать.

Но явно не для удовлетворения потребности программистов изобретать и оставлять след в истории.

А есть среди моих читателей читатели (sic!) моей книги? Напишите мне все, что вы о ней думаете!

Непопулярное мнение: большинство противников гибких методологий (в частности Scrum, Kanban, Scrumban и SAFe) не имеют опыта работы с ними.

Ваше выходное чтиво: пост от Кори Куинна (известного в определенных кругах амазонщика) о том, как переплюнуть AWS. Интересный опус и более того - мне есть что на это ответить.

Оставайтесь на связи.

Обещанная ответка: https://medium.com/@thomas.storm/how-to-really-compete-with-aws-240052b74cba

Кто сегодня придет на меня посмотреть, напишите мне после выступления, интересует ваше мнение.

От себя хочу добавить, что этот доклад ориентирован на тех, кто в AWS ни зуб ногой. Если вы с ним хоть немного работаете, вам будет интересна только часть про сертификации, которая будет в конце.

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

Сегодня мне удалось успешно сдать экзамен AWS Certified Solutions Architect Professional.

Как и следовало ожидать, этот экзамен - проверка на выносливость. 190 минут, 75 вопросов, вставать и отходить от ноутбука нельзя, проктор-экзаменатор непрестанно бдит.

Как и предыдущий экзамен (AWS Certified SysOps Associate) я сдавал "на шару" - без должной скрупулезной подготовки и зубрежки, надеясь выехать за счет своего опыта. За счет опыта и выехал.

Вопросы, в которых фигурировали AWS Organizations, CloudFormations и IAM, щелкал на раз - в этих темах я собаку съел, да и не только собаку. На некоторые вопросы я отвечал уверенно за счет того, что я с этим работал (AWS SMS, DMS, Athena, Glue). Если вы мало работаете с AWS, то экзамен будет сложный.

Из минусов: некоторые вопросы, как и следовало ожидать, продают AWS. К радости их было немного, да и продажа была не такая агрессивная, как была у меня на Certified Developer Associate.

Из плюсов - это отличный экзамен для роли Solutions Architect. Каждый кейс, каждый вопрос, расписанный чуть ли не на А4, ожидает от вас компетенций именно архитекторских, где из всех стульев нужно выбрать тот, где пики уже затупились.

Да-да, в CSA Pro есть вопросы, ответы на которые все "правильные", потому что решают поставленную задачу тем или иным образом (а вам нужно выбрать тот ответ, который лучше удовлетворит потребность вашего заказчика). Но есть вопросы, где все ответы ужасны, и нужно выбрать наименее ужасный.

Зачем такие вопросы есть в экзамене, мне не до конца понятно. Надеюсь, речь как раз о тех самых trade-off'ах, которые ожидают архитектора тут и там.

Скажите, что у меня стокгольмский синдром, но это лучший экзамен из всех, что я сдавал в своей жизни. На втором месте заслуженно останется экзамен по Операционным Системам (Н.А. Иванов one love).

Во всей этой истерии вокруг переименования мне интересно, дойдут ли ушлые руки всех униженных и оскорбленных до "демонов".

Этимология термина "демон" в ИТ и UNIX не имеет никакого отношения к авраамическим религиям... Но когда это кого-то останавливало?

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

Я продолжаю придерживаться тех же взглядов, что и всегда: архитектор, как отдельная должность - абсолютно бесполезная трата денег. Это роль, которую могут брать на себя один или более человек, совмещая ее с основной деятельностью (разработкой, управлением продуктом, you name it).

В своем предпоследнем посте я обращаю внимание на то, как меняется работа человека в момент, когда он тратит в почтовом клиенте больше времени, чем в терминале или редакторе кода. Я не шутил, когда говорил, что лишь огромный балласт из непрочитанных книг, Hackerrank и нехватка рук у инженерных групп помогают мне оставаться в форме. Я осознаю свои обязательства перед клиентом и не намерен его подводить из-за неправильного архитектурного решения.

Однако я вижу, что неприемлемо малое количество архитекторов поступает подобным образом. Более того, если (бес-)"полезность" разработчика видна практически сразу, то архитектору удается оставаться некомпетентным лодырем очень долгое время, и последствия этого выявляются вовсе нескоро.

Если вообще выявляются.