среда, 8 августа 2018 г.

О мотивации

Я не могу делать вещи, которые мне не интересны. От слова совсем.

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

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

Как и для многих других, меня в общем случае мотивируют три вещи: автономность (autonomy), мастерство (mastery) и цель (purpose). Но они для меня играют разное значение.

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

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

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

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

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

Возьмем, к примеру, саморазвитие.

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

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

понедельник, 30 июля 2018 г.

Эффект плато

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

среда, 4 июля 2018 г.

Сдвиг массива влево на 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]

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

вторник, 3 июля 2018 г.

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

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

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

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

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

пятница, 20 октября 2017 г.

Анонс конференции 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 есть поддержка обобщений и значимые типы. К сожалению, я могу предположить результат сравнения, но последить за таким поединком не отказался бы.

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

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

среда, 6 сентября 2017 г.

Структура управляемого объекта. Части 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-а.

четверг, 24 августа 2017 г.

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

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

Друкер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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