CTO Day от Yandex

Был на этих выходных на очень интересном мероприятии от Yandex в Дубае, где собралось большое количество технических лидеров (не только из российских компаний) обсудить интересные вопросы. Честно говоря, я давно уже устал ходить на конференции в качестве слушателя, в этом году сократил свои походы в качестве спикера, но вот такие мероприятия как организовал Yandex мне нравятся. В одном месте собрались куча умных людей, с которыми можно разговаривать часами на разные темы и узнавать в дискуссии что-то новое, а это очень важно для меня. Кажется, что с самого детства главным качеством у меня было любопытство и желание узнать как и что устроено вокруг меня (правда, скорее в концептуальном плане, а не практическом). С годами опыт увеличивался и многие вещи становились очевидными и находить новую пищу для утоления информационного голода становилось тяжело: статьи сменялись книгами, книги сменялись whitepapers, добовлялись книги из смежных тем ... Но вершиной являются личные встречи с одаренными людьми, а ребятам из Яндекса удалось собрать очень плотный состав:) Классно, что даже во время перелета туда/обратно я сидел с умнейшими соседями и даже не особо тянулся к книге:)

Если же говорить про программу, то она тоже была очень интересной:
- В первый вечер у нас было приветственный ужин с IT стендапом, который выдался отменным
- Следующий день мы начали с доклада Леши Гусакова про путь ML от RnD к необходимой технологии для современных компаний. Доклад был не просто интересным, но и наполненным юмором, как будто он продолжал традицию стендапа
- Продолжилось все лекцией Вячеслава Дубынина про мозг и естественные и искусственные нейросети - я уже несколько раз видел его лекции про мозг вживую, читал книги и смотрел записи лекций на Youtube, поэтому заранее знал, что это будет превосходно (кстати, про одну из лекций я уже рассказывал)
- Дальше была дискуссия про кибербезопасность, из которой следовало, что надо делать софт безопасно, а небезопасно делать не надо
- А после кофебрейка наш монолитный коллектив должен был выбрать в какой дискуссии поучаствовать: про сложные переговоры, применение ML или governance технологического стека в компании. Я выбрал тему про governance и это было интересно
- Вечером второго дня был ужин, который плавно перерос в спонтанный fuckup nights, когда в небольшом номере собралось 10+ человек и начало обсуждать истории про факапы, которые были в нашем прошлом (и этот вечер закончился только в 4 утра)
- Последний день был посвящен экскурсиям, но я улетал в середине дня, поэтому перед отлетом мы с друзьями сгоняли на приватный пляж, окунулись в море, а дальше отправились в аэропорт и вернулись в холодную Москву

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

#Software #Management #Leadership #Vacancy #Architecture

ЦЕХ 4 - Урок #7 "Книга по полочкам. Эксперт — Юлия Потемкина"

Продолжая серию постов про свое обучение книгописательству (смотри предыдущие посты: 1, 2, 3, 4, 5 и 6), я расскажу про седьмой урок. В этом уроке Юлия, ведущий редактор издательства "МИФ", рассказала о своей работе и о том, как выглядит книга структурно. Честно говоря, я после этого урока понял, что я бы хотел привлечь к улучшению своей книги редактора, работа которого похожа на то, что происходит на code review. Он проверяет качество материала, аудиторию, на которую книга ориентирована, и подходит ли она для конкретной аудитории, также он учитывает платёжеспособность читателя и определяет, в какую нишу и серию книга должна быть вписана. Дальше он идет по следующим шагам
- План и оформление книги - правильно ли оформлен и структурирован материал, чтобы быть удобным для читателя. Важно, что оформление и формат книги должны соответствовать аудитории и целям использования.
- Оглавление и структура книги - для читателя важна логика и структура книги, а также важно аккуратно выходить из книги (финальный аккорд). Также читателю полезна рубрикация и оглавление, по которому он понимает содержание книги
- Объем и структура книги - объем книги зависит от читателя. Важно делить книгу на главы, разделы и подразделы для удобства читателя.
- Дополнительные тексты и иллюстрации - иллюстрации в книге добавляют сложностей, поэтому они должны быть обоснованы с точки зрения пользы для читателя. Также необходимо учитывать их влияние на себестоимость книги и сроки сдачи, а также учитывать работу с авторскими правами
- Диаграммы и таблицы - они должны быть простыми и наглядными, чтобы облегчить понимание информации. Важно учитывать единицы измерения и обобщать данные в заголовках.
- Происхождение данных - сточники данных должны быть указаны, чтобы избежать проблем с авторскими правами.
- Аппарат издания - это название для обвязки книги в виде предисловия, послесловия, благодарностей, глоссария и других справочных материалов.
- Оценка и перестройка структуры книги - так как важно учитывать потребности и интересы читателя при создании книги , то издатель может предложить свои идеи и помощь в перестройке структуры книги.

#Writing #SelfDevelopment #Management

Let's talk about DX, Baby! - Jo Franchetti - NDC London 2024

Этот доклад Джо Франкетти на конференции NDC {London} 2024 посвящен теме developer experience (DX, DevEx), по которой относительно недавно вышло несколько whitepapers. Эта тема мне импонирует, поэтому я расскажу кратко о чем была речь в этом докладе:
- Автор рассказывает про важность DX, рассказывая историю о разработчике, который столкнулся с трудностями при интеграции нового инструмента.
- Из этого выводятся три составляющие подхода DX: cognitive load, flow state и feedback loops
-- Когнитивная нагрузка - это объем информации, который разработчик должен обработать для выполнения задачи.
-- Состояние потока - это состояние ума, когда человек полностью погружен в свою деятельность и чувствует себя мотивированным и эффективным.
-- Циклы обратной связи - это скорость и качество ответной реакции на произведенные действия
- Дальше звучит тезис о том, что если работать над улучшением опыта разработчика, то это может снизить когнитивную нагрузку и повысить продуктивность.
- Для попадания в состояние потока нам нужна среда, где есть баланс между уровнем мастерства и задачами, которые ставятся перед разработчиками. Это позволяет разработчикам чувствовать, что они контролируют процесс и могут использовать инструменты.
- Циклы обратной связи позволяют разработчикам получать информацию о том, правильно ли они выполняют задачи и где они испытывают трудности (условно запуски CI/CD с прогоном тестов дают полезную обратную связь, но если мы ее ждем часами, то мы теряем в эффективности)

- Для измерения и оценки изменений можно использовать опросы (NPS, CSAT), оценку качества кода (code complexity, code coverage, number of bugs, number of issues), developer productivity (тут мерить можно по разном), development lifecycle
- Дальше автор предлагает разделять Internal DX и External DX
-- Internal DX - тут фокус на улучшении продуктивности, выравнивании с бизнес-целями
-- External DX - тут фокус на adoption rates, вовлечении коммьюнити и промотировании продукта более широкой аудитории
- А дальше автор показывает гигиенические факторы при создании репозиториев с кодом:
-- Соблюдение стандартов кодирования
-- Использование dev контейнеров и codespaces
-- Избегание глобальных настроек
-- Создание всеобъемлющего readme, включающего введение, цели, задачи, ключевые особенности, использование, настройку, ограничения, рекомендации по внесению изменений, контактные данные, кодекс поведения, лицензию.Грамотное написание технических текстов, понимание аудитории, создание образа читателя.
-- Создание понятного кода - функций без побочных эффектов, функций с меньшим количество аргументов, promises over callbacks, ранний возврат из функций, etc. Важно отслеживать читаемость кода, так как большую часть времени мы поддерживаем уже созданный код, а не создаем новый. Сложный код увеличивает когнитивную нагрузку и ухудшает developer experience

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

P.S.
Я уже писал на тему developer productivity и developer experience несколько статей
- В общем про подход к теме developer productivity
- Обзор whitepapers
- Обзор доступных коммерческих платформ

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

Вакансия Staff Engineer в a/b платформу @ Tinkoff

Я ищу крутого инженера в команду, которая разрабатывает систему для проведения экспериментов. Эта система позволяет автоматизировать все этапы проведения экспериментов от планирования до подведения итогов и, существенно снизить расходы на проведение экспериментов. Интересно, что за эту систему отвечает мой коллега, Андрей Цыбин, с которым мы уже записывали серию подкаста "Code of Leadership" про систему продуктовой аналитики Statist. В итоге, сейчас у Андрея есть позиция крутого инженера, что выступит забойщиком при создании системы подведения итогов по экспериментам, которая позволяет оценить результаты проведения тестов по набору метрик и статистических критериев к ним, и на основе этих данных принять решение по эксперименту. План таков, что вокруг этого инженера соберется команда, что сможет сделать Тинькофф еще более data driven.

Кстати, я уже рассказывал про книги на тему статистики, которые были бы полезны такому инженеру
- Как лгать при помощи статистики (How to Lie with Statistics) - на пальцах объясняется как врут с помощью статистики, а отсюда становится ясна мотивация создания системы подведения итогов экспериментов
- Understanding Statistics and Experimental Design. How to Not Lie With Statistics (Статистика и планирование эксперимента для непосвященных) - в этой книге рассказывается про дизайн экспериментов и математику, что стоит за ними
- Доверительное a/b тестирование (Trustworthy Online Controlled Experiments) - а эта книга позволяет еще и понять как сделать платформу для проведения экспериментов на уровне всей компании

Ну а теперь немного про наши ожидания от идеального кандидата (tl;dr - надо быть крутым инженером)
- Опыт разработки на любом из уважаемых языков программирования (C++, Python, Java, Kotlin, Scala, Golang, C#)
- Опыт проектирования масштабируемой инфраструктуры для распределенной обработки данных, включая ее мониторинг. Будет плюсом опыт работы с инструментами обработки данных, таких как: Apache Spark, Apache Airflow и т.п.
- Опыт проектирования моделей данных, выбор подходящего способа хранения и работы с такими хранилищами как: S3, HDFS, Clickhouse, Greenplum
- Будет плюсом знание математической статистики и понимание методологий проведения А/Б экспериментов (можно поботать книги, что я указывал выше, чтобы понять насколько это интересно)

Ну а теперь что придется делать кандидату (tl;dr - надо делать то, что делают крутые инженеры)
- Планировать техническое развитие продукта (тех долг, улучшения)
- Участвовать в разработке архитектуры и спецификации задач
- Участвовать в процессе разработки новых фич от проектирования до ввода в эксплуатацию (да, у нас разработчики релизят код на прод)
- Улучшать кодовую базу как основных сервисов, так и вспомогательных библиотек
- Вести внешную коммуникацию с другими командами, стекхолдерами и руководителями
- Отвечать на своевременную доставку фич

Если вам понравилась позиция, то пишите в личку @apolomodov и @tcandrei

P.S.
А в общем про staff инженеров мы говорили с моим коллегой, Лешей Тарасовым, в другом выпуске Code of Leadership.

#Vacancy #Statistics #Data #Staff #Leadership #Architecture #SoftwareArchitecture