ЦЕХ 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

Code of leadership #15 - Interview with Roman Lebed about Information security

В пятнадцатом выпуске подкаста "Code of Leadership" я пообщался с Романом Лебедем, архитектором из департамента информационной безопасности Тинькофф. До Тинькофф Роман руководил командой Red Team и занимался прикладными исследованиями в области безопасности приложений и операционных систем. В этом интервью мы обсуждаем подходы к безопасности в современных технологических компаниях. За 50 минут мы успели рассмотреть следующие моменты

- Как выглядит работа security архитектора в Тинькофф
- Требования к экспертам безопасности
- Как выстроено взаимодействие с командами разработки
- Какие подходы к безопасности существуют в Тинкофф
- Роль архитектора в команде
- Метрики безопасности
- Об "информационной безопасности" как профессии
- Обучение и развитие SDE (software development engineers) и shift left подходы
- Рекомендации для начинающих специалистов

P.S.
У Романа есть свой канал, посвященный безопасности @offensive_thread, на который можно подписаться, а также можно почитать книги, которые он рекомендовал
- Building secure and reliable systems - я про нее уже как-то рассказывал
- How to Linux works
- Android Internals::A Confectioner's Cookbook
- MacOS and iOS Internals (3 тома)
- Компьютерные сети (Таненбаум и ко)

Также у Ромы есть ряд интересных вакансий в его команды
- Архитектор ИБ/ Security Engineer & Architect (SEAR) в команду защиты Core Services
- AppSec TechLead в команду защиты периметра
- DevSecOps инженер в команду защиты периметра
- Разработчики Golang в команду VMP (Vulnerability Management Platform)

Если одна из вакансий вам интересна, то пишите Роме (@Ziv00s3)

#Infosec #Leadership #Architecture #Software #Processes #ProductManagement #Management #Security

Ты уволен. С уважением, ChatGPT (Выпуск подкаста "Карты, деньги и продукт")

Интересный выпуск подкаста "Карты, деньги и продукт", в котором мои коллеги обсуждают влияние искусственного интеллекта на различные профессии, но преимущественно в продактов. Очень интересно слушать гостя, Витю Тарнавского, директора AI Центра Tinkoff, который рассказывает о текущих возможностях AI, а также про его перспективы. Если сократить, то ребята затронули вопросы
- Как AI повлияет на разные профессии - тут больше всего эффекта на digital профессии, так как они уже оцифрованы. А вот профессии из реального сектора сложнее автоматизировать. Для того, чтобы не оказаться на профессиональной обочине надо прямо сейчас пробовать и применять AI инструменты для помощи в своей работе, например, copilot для написания кода, тестов, ...
- Не во всех областях LLMs можно использовать эффективно - у сетей есть галлюцинации и иногда это не ок (но для условной болталки это не проблема)
- В Тинькофф мы активно внедряем технологии искусственного интеллекта для автоматизации работы продуктов и сервисов. Из свеженького можно почитать нашу новость про вселенную ассистентов от 25 апреля 2024 года
- Можно пробовать использовать AI для помощи в принятии решений - например, подбор рецептов по продуктам из холодильника или прогнозированию расходов на фастфуд
- Другая крутая тема - это использование AI для помощи в корпоративном управлении. Условно в большой корпорации всегда есть проблемы с управляемостью (централизацией/децентрализацией) и стоимостью аппарата управления. Примерно про это я писал в посте про developer productivity, называя это подходом сверху-вниз
- Все бегут в сторону AI, потому что есть ожидание, что он может приносить деньги, автоматизируя процессы и создавая новые прогрессивные продукты. Витя упоминает конкретные примеры
- Ну и в финале этой серии гость и ведущие выражают надежду на наступление "пелевинских времен", когда технологии будут помогать в жизни и трансгуманизм станет реальностью.

#AI #ML #Leadership #ProductManagement #Productivity #Management