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

Предполагается, что одновременно ведется работа только над одной главой, в соответствии с этим и проставляются сроки сдачи материала. Что интересно - издатель изначально давал мне по 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. Целая страница не состоит только из кода или скриншотов (т.е. не больше 75%).
3. Грамматические конструкции понятны читателю.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Список огромный, но самый излюбленный дискурс - 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