Человек и машина

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

Фильм Дудя про талантливых русских ребят из долины я посмотрел не сразу. Понадобилось несколько постов в соцсетях, предлагающих девушкам поставить 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? Откуда ж мне знать.

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

Всем, кто хочет сдавать экзамены 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ого июня.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Россия не остается в стороне, и уже сейчас можно подать заявку на https://hackthecrisisrussia.ru/.

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

Когда все это закончится, COVID-19 (да, я помню про свое обещание) еще ударит по нам и нашей экономике, и именно поэтому сейчас не стоит тратить время впустую.

А дальше - дела механические: тираж, маркетинг, раздача слонов и прочие мелочи.

Писать книгу было... средне. Иногда текст шел сам, иногда было невероятно тяжело. С Template Macros прошло легко, над Custom Resources страдал. Тяжелее всего, как ни странно, далась последняя глава - надевать шапку "визионера" оказалось сложнее донесения простых истин.

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

Завтра ожидайте от меня хорошую новость. ;)

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

Чтобы сократить количество комментариев, вы, как автор, можете сделать следующее:
1. Убедиться, что повествование строится в соответствии с методическими рекомендациями издателя (вам их предоставят).
2. Целая страница не состоит только из кода или скриншотов (т.е. не больше 75%).
3. Грамматические конструкции понятны читателю.

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

Редактор будет задавать вопросы в стиле "Код выше будет понятен читателям?", а вы будете смотреть на код, видеть там print("Hello, World") и невольно думать, что с редактором что-то не так.

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

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

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

Приятно или нет, но вы будете очень удивлены.

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

Предполагается, что одновременно ведется работа только над одной главой, в соответствии с этим и проставляются сроки сдачи материала. Что интересно - издатель изначально давал мне по 2 рабочей недели на главу, вне зависимости от ее размера и темы. Проще говоря, у вас что на вступительную главу на 10 страниц, что на огромную главу на 50 будут выдавать одинаковое количество времени.

Разумеется, это можно и нужно оспаривать. Более того, если однажды возьметесь за заказ - я настоятельно рекомендую докидывать как минимум 5 рабочих дней на сроки по тем главам, тема которых вами не изучена на 100%! Объясню почему.

CloudFormation я знаю хорошо. Очень хорошо. Я давно с ним работаю, застал времена, когда его можно было писать только в формате JSON, и ликовал, когда завезли cfn-init. Однако, в моей книге есть главы про SAM и CDK, и если SAM это кастрированный CFN, то CDK - это нечто модное, стильное и молодежное, нечто нетронутое моим чопорным "оно работает" взглядом, но прекрасно ложащееся на мое повествование (почему - тема отдельного поста).

Ничего, кроме как досконально это изучать, не остается. Потому и написание главы состоит из следующих ступеней.
1. Пишем набросок черновика с заранее заготовленным текстом (вступление, водичку, выводы и так далее).
2. Подробно изучаем тему главы, пишем прототипы, испытываем, ловим все грабли, просматриваем документацию, прорабатываем лучшие практики (Опциональная ступень, если экспертиза уже имеется).
3. Пишем и проверяем код, который будет поставляться с книгой.
4. Пишем главу, добавляя в нее куски кода, скриншоты, диаграмы.
5. Проверяем код еще раз, параллельно записывая демонстрационные видео.

Очевидно, большую часть времени занимают 2 и 3 пункты. Задача не просто пройтись по документации и нарисовать "Hello, World". Задача - от и до изучить тему и донести её до читателя в рамках интересного и понятного повествования.

Нередко во время написания прототипа может еще появиться новая идея ("А что если я сделаю тут по-другому и посмотрю, что будет?"). Тогда ее обязательно надо проработать и включить в книгу.

Так, например, у меня появилась мысль вручную проставлять True и False в значения Conditions (Спойлер - так делать нельзя).

Но это еще не самое сложное в подготовке и сдаче материала.

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

Дальше (новоиспеченного) автора ожидают следующие стадии принятия неизбежного:
1. Подготовка наброска книги, рассмотрение издателем, подготовка и подписание контракта
2. Написание и редактура первичных черновиков
3. Технический обзор, редактура финальных черновиков
4. Производство

Набросок (book outline) - по факту текстовый документ-форма, в котором вы указываете: о чем и почему будете писать; какие части будут у вашей книги, какие главы; какие навыки приобретут читатели и так далее. Заполнение наброска занимает 1-2 дня, после чего его рассматривает издатель и принимает решение - начинать такой проект или нет. Как только положительное решение принимается, вам присылают шаблон контракта на проверку и запрашивают персональные данные для заполнения полей в контракте.

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

Отдельно стоит упомянуть название книги, а именно слово "Mastering". Нет, это не понты автора - у Packt есть 3 "уровня" книг: Learn, Hands-On и Mastering, каждая из которых имеет свою аудиторию.

Если книги Learn направлены на аудиторию уровня Beginner, а конечный результат будет Intermediate, то Mastering - на уровень Intermediate, с ориентацией на то, что после книги вы должны знать все-все-все. Неоспоримым плюсом этой серии является отсутствие необходимости разжевывать прописные истины, а минусом - писать надо понятно о сложном.

Так что если вы собираетесь купить книгу о Packt, обращайте внимание на название. В одной группе коллега жаловался, что читает книгу про Elastic, а там все написано как для детей, и ничего нового из нее не усвоить.

Называлась она "Learning Elastic Stack" :)

Книгу писать я решил не сам, лукавить не стану. Прошлой осенью со мной вышла на связь сотрудница Packt с предложением написать для них книгу по CloudFormation, дескать ей очень понравился мой блог на Medium.

"Вот она, слава!" - подумал я, но моя муза предложила все хорошенько обдумать. Писать книгу - тяжелый труд, особенно когда ты не Стивен Кинг, а у издателя жесткий дедлайн. Я потратил пару дней, шерстя треды на Hackernews, посвященные авторству для издателей типа Packt и O'Reilly, и узнал следующее.

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

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

И это прекрасно понимаю не только я, но и все авторы, когда берутся за заказ. Мотивация у таковых следующая:
- Престиж и возможность добавить слово "writer" в профиль LinkedIn (т.е. личный бренд)
- Новый опыт
- Верхние 4 ступени пирамиды Маслоу

С моей стороны к этому еще добавляется удовлетворение потребностей "вбить в голову элементарные, по моему мнению, вещи" и "если ты делаешь что-то хорошо, не делай это бесплатно".

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

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

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

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