Эффект плато

Время от времени с головой и карьерой начинают твориться довольно страшные вещи: все начинает если не напрягать, то точно приносить меньше удовольствия. Работа не прет. Проекты не прут. Ничего новое не радует и не интересует. Вопрос: почему?

У меня есть некоторые мысли по этому поводу.

Есть такая штука – допамин. Он вырабатывается, когда вы ожидаете доставки нового ай-фона, «встречи» с любимой/любимым вечером или в момент укуса вкусного мороженого жарким летним днем. Допамин – это сильнейшее штыриво, которое вырабатывается от ожидания чего-то приятного или прямо в момент его наступления.

Когда начинается карьера программиста, то с допамином нет никаких проблем. Ты каждый день узнаешь что-то новое: технологии, процессы, паттерны, практики. Вокруг все новое и моменты «просветления» происходят довольно часто. Возникает чувство, что мозг и опыт развиваются по закону Мура и каждые 18 месяцев количество знаний удваивается.

Тоже самое происходит и с первыми проектами: ощущение «творения» возникает постоянно. Исправил маленькую багу – молодец. Применил новый паттерн – красава. Починил билд – отлично. Задизайнил и довел до ума новую фичу – да вообще тебе цены нет.

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

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

И потом мир начинает немного меняться.

Ну, с миром-то все нормально. Но твое восприятие становится несколько иным.

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

Это же происходит с карьерой и ощущением от завершенных задач. Выше «синьера» прыгать сложно, да и не ясно, куда именно. А с задачами вообще беда получается: все одно и тоже, формошлепство, дата-сайенс, веб, базы данных. Декораторы, синглтоны и фабрики. И дурацкие обсуждение того, чем монады хороши, и почему ООП уже не торт.

Так что же происходит?

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

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

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

Есть несколько способов смягчения этой проблемы.

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

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

В-третьих, можно прислушаться к себе и понять, что же может толкать тебя изнутри. Если нравится больше кодить, то может стоит забить на свои глупые тим-лидские амбиции и заняться архитектурой или стать «просто разработчиком»? А может тебе просто нравиться изучать что-то новое, так может стоит продолжать это делать, даже если это никак не поможет твоей карьере?

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

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

Сдвиг массива влево на N элементов

Есть ряд способов сдвинуть массив влево на N элементов. Можно взять и сделать N сдвигов по одному элементу, получив квадратичную сложность. Можно создать целевой массив по размеру исходного и вычислить положение каждого элемента после сдвига. Хорошо, но скорость линейна, затраты по памяти - тоже.
Если чутка подумать, то можно придумать реализацию, которая мутирует массив и дает линейную скорость и константные затраты по памяти. Но есть один очень элегантный способ – из 3-х строк на основе чудо Span of T из System.Memory:

public static void RotateLeft(int[] input, int direction)
{
    input.AsSpan(0, direction).Reverse();
    input.AsSpan(direction).Reverse();
    input.AsSpan().Reverse();
}

Идея такая: чтобы сдвинуть массив из K элементов на N элементов влево, нужно перевернуть первые N элементов в массиве, затем последние K - N -1 элементов, а затем перевернуть весь массив:

// direction == 2, input.Length == 7
input.AsSpan(0, direction).Reverse();
// [2][1][3][4][5][6][7]
input.AsSpan(direction).Reverse();
// [2][1][7][6][5][4][3]
input.AsSpan().Reverse();// [3][4][5][6][7][1][2]

Получается два прохода по массиву, но зато с читабельностью решения все очень ОК.

Welcome, так сказать, back:)

Мне вот тут подумалось, что блоггинга мне не хватает. Причем не очень хочется писать чего-то длинное и сильно умное. Для этого, у меня теперь на английском блог есть. Хочется чего-то простого и легковесного, типа журнала живого. Вроде бы есть всякие Г+ и фейсбуки, но их формат мне все равно не нравится. Если захочешь чего-нить своего потом найти там, заморишься.

Так что я решил восстановить блог, но в формате, о чем пишется, о том и буду писать. В основном о технологиях, о книжках читаемых и мыслях при этом в голову приходящих.

Вот и сейчас просто хочется поделиться загадкой, которую вчера решал:

Есть пять нор, расположенных в ряд. В одной из них сидит лиса. Каждую ночь лиса перебирается в соседнюю норму слева или справа. Каждое утро вы можете проверить одну нору на выбор. Какая должна быть стратегия проверки нор, чтобы в конечном итоге лиса была поймана?

Анонс конференции DotNext 2017 Moscow

Пришло время очередной конференции DotNext Moscow и организаторы предложили их поддержать, на что я с радостью согласился. Итак, промокод TeplyakovPromo дает скидку в 10%.

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

День 1

1. Андрей Акиньшин – Поговорим про performance-тестирование

Андрей – один из авторов популярной микро-бенчмарк фреймворка BenchmarkDotNet, который в этом году (если не ошибаюсь) присоединился к .NET Foundation и является маст-хев тулом для всех любителей пооптимизячить.

Тема перф-тестирования, на самом деле, очень интересна и весьма слабо покрыта в тырнетах. Я не знаю, о чем будет говорить Андрей, но я бы выделил несколько аспектов:

· Бенчмаркинг

· Автоматизированное тестирование потребления памяти определенным куском кода

· Автоматизированная валидация производительности путем запуска интеграционных тестов и сбора телеметрии

В моем текущем проекте, например, весьма серьезное внимание уделено последнему пункту, когда система прогоняется на тестовом сервере с разными сценариями, а анализ ведется путем анализа телеметрии.

2. Сергей Быков – Назад в будущее: построение эффективных облачных сервисов с помощью Orleans

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

3. Дино Эспозито – I have a microservices architecture and I didn’t know

Опять-таки, тема не моя, но Дино – это очень именитый спикер, и тема весьма наболевшая.

4. Марк «Я могу и ФП, и ООП» Сииман – From dependency injection to dependency rejection

Этот доклад я бы ни за что не пропустил. Макр – известный спикер, автор книги “Dependency Injection in .NET”, а ныне активный участник F# Community. Это значит, что Марк понимает, как ОО, так и ФП миры, что позволяет ему выбирать лучшее из двух и вдумчиво объединять эти парадигмы (ИМХО, лучший подход из всех возможных – ОО-компонентизация и «слоеность» + ФП реализация компонентов).

5. Raffaele Rialdi - Runtime code generation techniques in real life scenarios

Тема генерации кода во время исполнении мне близка и я ею достаточно часто пользуюсь в работе. Одним из таких примеров является оптимизация фабричного метода по созданию объектов, описанная в посте Dissecting the new() constraint in C#: a perfect example of a leaky abstraction. Даже в моей практике набралось с десяток примеров, и я бы с радостью послушал об опыте других.

6. Karel Zikmund – High Performance Networking in .NET Core

Однозначный маст-визит для всех, кто интересуется разработкой высокопроизводительных приложений в .NET. Karel работает в команде .NET Core и хорошо знает, о чем будет говорить. Сейчас идет серьезный пуш в сторону low-allocations и в целом high-performance для всего сетевого стека и других ключевых компонент.NET.

Я бы сказал, что на этот доклад нужно идти, даже если вы не интересуетесь high-load и всем таким, просто, чтобы посмотреть, как делается история. Все же не каждый год крупные компании решаются на серьезный редизайн core-компонентов.

День 2

1. Егор Бугаенко – TDD вверх ногами

Как вы, наверное, знаете, у меня весьма однозначное отношение к тестированию и весьма неоднозначное отношение к TDD. А тут такой повод! Егор – весьма интересный спикер, который отличается несколько необычными взглядами на общепринятые вещи. Я не знаю (вру, знаю), что будет на выступлении, но интересная точка зрения автора и интересный доклад гарантирован.

2. Вагиф Абилов – Akka Streams для простых смертных

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

3. Валерий Петров – Модель памяти в .NET

Модель памяти – это достаточно мутная, вывихивающая мозг концепция, готовить правильно которую могут с десяток человек на планете. Но это не значит, что вам не нужно знать, что это такое.

Ну а если эта тема не интересна, то есть смысл обратить внимание на доклад Володи Кочеткова Побеждая инъекции.

4. Денис Иванов - Apache Kafka и рективные микросервисы на .NET Core

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

5. Виталий Езепчук – Поединок: .NET Core против Java

Идея доклада – огонь: сравнить два популярных ран-тайма. Я понятия не имею, как можно провести честное сравнение, когда у этих двух сред столь разная история, и столь разный набор плюсов и минусов. Java славится значительно бОльшим числом различных оптимизаций в ран-тайме, в то время, как в CLR есть поддержка обобщений и значимые типы. К сожалению, я могу предположить результат сравнения, но последить за таким поединком не отказался бы.

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

Организаторам – респект, а вам – отличной конференции!

Структура управляемого объекта. Части 1 и 2

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

Так вот, меня всегда интересовали несколько моментов с точки зрения структуры (layout) объекта: почему управляемый указатель указывает в середину объекта? Почему object header хранится по негативному индексу и что же именно может храниться в заголовке объекта?

На первый вопрос ответ дается в первом посте: Managed Object Internals, Part 1. Спойлеры: причина историческая, хотя есть и определенные сведения о том, что причины были связаны с эффективностью.

Во втором посте – Managed Object Internals, Part 2. Object header layout and the cost of locking в деталях рассматривается структура object header-а, а также концепция thin lock-ов. Интересно, что thin lock-и мало где описаны и о них мало кто знает. Thin lock – это более оптимальная реализация блокировок, добавленная в CLR 2.0, которая позволяет синхронизироваться на объекте с нулевыми (практически) накладными расходами за счет сохранения информации о блокировки внутри object header-а.

О книге Ф. Друкера «Эффективный руководитель»

Неспособность сконцентрироваться на чем-то более вменяемом, привели меня к чтения очередной около менеджерской книги. На этот раз, книги «Эффективный руководитель» Друкера.

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

Но, как это часто бывает, что-то пошло не так.

Ну, для начала, первое издание книги написано 50 лет назад. Что само по себе ничего не значит. Дядюшка Брукс поведал нам о своей истории 42 года назад, и ничего, помимо некоторых технических архаизмов, книга сегодня заходит просто на ура.

ЦИТАТА: Еесли и существует какой-нибудь главный секрет эффективности, то это концентрация.

У Друкера архаизмы проявляются в нескольких вещах. Многие примеры идут из 60-х, что неплохо, само по себе. Но часто отсылки идут к истокам и решениям, принятым в 20-х годах, в таких компаниях как Bell Telephone System или General Motors с последующим анализом их влияния на современность. А вот современность по меркам книги – это и есть те самые 60-е. Нет ничего плохого в анализе действий Макнамары, Эйзенхауэра или Кеннеди, но мне их сложно анализировать, поскольку я недостаточно хорошо знаю то время. Моя «современность» начинается несколько позже. Значительно позже.

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

Но самая главная проблема книги, ИМХО, это количество пространных рассуждений.

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

О`Кей. Согласен со всем. Но, ..., я как-то не понял, что автор хотел этим сказатьJ. Конечно, это не совсем честно, выдирать цитату из завершающей части книги и с ее помощью обвинять автора в многословности. Тут и перевод мог добавить сложности, да и мои способности восприятия мудрости могли быть не на высоте.

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

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

ЦИТАТА: Руководитель, подбирающий в организацию людей без недостатков, в лучшем случае наберет посредственный персонал.

Вот, как раз хороший пример, связанный с подбором персонала.

ЦИТАТА: Эффективно работающие руководители знают, что их подчиненным платят за выполнение работы, а не за то, чтобы они радовали своих начальников.

Но ведь хорошо!

ЦИТАТА: Эффективные руководители редко питают иллюзии относительно того, что две посредственности добьются такого же результата, как один блестящий работник. Им известно, что, как правило, двое посредственных работников работают даже хуже, чем один хороший, так как они просто мешают друг другу.

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

ЦИТАТА: Подбирая кадры, нужно обращать внимание на сильные стороны сотрудника в какой-либо одной области, а не на посредственные навыки во многих сферах.

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

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

О книге Джона Сонмеза “The Complete Software Developer’s Career Guide”

Если честно, у меня не совсем однозначное отношение к автору книги – Джону Сонмезу (John Sonmez). Это довольно известный парень, автор пары книг, 55 курсов на Pluralsight (о чем он напоминает не менее 10 раз в своей последней книге), автор блога SimpleProgrammer.com и ютюб канала Simple Programmer. Он «вышел на пенсию» в 32 и «отдыхает» в свое удовольствие, работая на себя часов по 8 в день.

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

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

Теперь к книге.

По словам автора, книга “The Complete Software Developer’s Career Guide” покрывает все аспекты карьеры программиста: начиная от обучения и поиска работы, заканчивая продвижением по службе и началом своего дела.

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

Поиск работы. Очевидно, что для разработчиков с разным уровнем некоторые знания будут неактуальны. Если вы уже давно работаете, то вопросы выбора колледжа или код-кампа будут, интернатуры, поиска первой работы и т.п. будут не актуальными. Хотя если у вас есть детки, то, вполне возможно, эти сведения будут не бесполезными.

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

Джон также дает советы по переговорам с HR-ами и явно советует не раскрывать карты о своей текущей зарплате и даже не называть свои ожидания. Дескать, кто говорит первым, тот оказывается в менее выгодном положении.

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

· Обзор чего-то нового, чтобы понять, что можно решить с помощью этого.

· Понять, как начать это что-то использовать.

· Узнать 20% этого нового, чтобы покрыть 80% юз-кейсов.

Обзор мира разработки ПО. Раздел мало полезный для профессионального разработчика.

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

Я обратил внимание, что корпоративные культуры, промоушены и другие вещи, связанные с карьерой, сильно отличаются «здесь» и «там». Если в Киеве сидение на месте уже является достаточным основанием для повышения зарплаты, то в больших конторах в Штатах это не так.

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

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

Очень понравилась мысль о любимом местном понятии “work/life balance”. Джон советует не противопоставлять эти два понятия, а сделать работу неотъемлемой и приятной частью своей жизни. Да, идеальная работа бывает лишь в сказках, но в наших с вами силах сделать ее разумно-приятной.

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

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

Собственный бренд и саморазвитие.

И тут Остапа понесло.

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

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

Для меня блоггинг также является осью саморазвития и основой сети общения.

Помимо блоггинга, автор рассматривает и другие моменты: менторинг, публичные выступления, домашние проекты, чтение книг и статей.

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

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

Сомнительные моменты.

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

Еще автор советует, очень советует, найти профессионального писателя резюме. Ну, сомнительно это для меня.

Да и водички с повторениями тоже прилично.

Главный вывод/мотив книги.

В книге много полезных мыслей советов, но ключево, имхо один: будьте последовательными. Нет, не так. Набросайте план и последовательно идите к его выполнению. План не должен быть точным. Над ним не нужно неделю работать.

И не рассчитывай на быстрый результат. Его не будет. Не будет быстрого продвижения по службе. Не будет сразу же восторженных комментариев к вновь созданному блогу. Даже посетителей толком не будет. Ничего. Это нормально.

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

Вердикт: чтиво.