Книжный куб

История российских компьютерных игр (#History) Недавно я 20 часов провел в самолете за 10 дней, прочитал книжку, статью и даже посмотрел документальный сериал про компьютерные игры. Сериал мне действительно понравился - я когда-то давно очень любил игры, но перестал играть 20 лет назад после того, как меня чуть не отчислили с Физтеха. В итоге, для меня этот документальный сериал рассказывал новые история об играх, в которые я не играл, но про которые слышал краем уха. Забавно, что игры меня нагнали - мой старший сын поступил на геймдизайнера и теперь я тоже чуть больше интересуюсь историей и дизайном игр. Если возвращаться к сериалу, то он состоит из 9 серий длиной в 35-40 минут, а каждый эпизод покрывает какой-то период развития индустрии игр в СССР, а потом и России. В сериале приняли участие ключевые фигуры российской игровой индустрии, включая создателя "Тетриса" Алексея Пажитнова, основателя "Денди" Виктора Савюка, автора Color Lines Евгения Сотникова, разработчика "ИЛ-2 Штурмовик" Олега Медокса и других значимых представителей отрасли. Ниже представлено содержание каждого выпуска 1. Советские игровые автоматы, "Электроника", "Тетрис", "Перестройка" и зарождение студии NIKITA 2. История Color Lines, студии Gamos и появление Dendy 3. Становление "Акеллы", создание "Корсаров", развитие локализации и феномен пиратства 4. Разработка "Вангеров", "ИЛ-2 Штурмовик", история Maddox Games и MMO "Сфера" 5. Создание культовых квестов "Братья пилоты" и "Петька и Василий Иванович" 6. Инди-игры - "Механоиды", "Мор.Утопия", Sublustrum 7. История социальных и казуальных игр, разработка Age of Magic и Beholder 8. Онлайн-проекты: World of Tanks, World of Warships, Caliber 9. Новые проекты со славянской тематикой: Slavania, "Сказки старой руси" и "Смута"13 В общем, документальный сериал мне зашел и показался стоящим. P.S. Помимо сериала вышла и отдельная книга с 27 интервью ключевых людей индустрии, которые появляются и в самом сериале. #History #Games

Глава "API Governance" из книги API Management - Part I (Рубрика #Management) Я уже дедал краткое саммари отличной книге "API Management", но сегодня хотел кратенько рассказать о главе про governance, читая которую я ловил очень много флешбеков:) Основные мысли, что я извлек для себя примерно такие 1. Слово "governance" нравится не всем, поэтому иногда его лучше не использовать, но авторы говорят, что

In fact, we’ll go as far as saying that it’s impossible to manage your APIs without governing them.

Поэтому тот или иной подход к governance существует и авторы предлагают модель для осмысленного выбора подхода 2. Этими элементами системы governance являются: decisions, management, complexity 3. Инженерная работа предполагает большое количество решений, причем часть решений влияют на то, как себя будет чувствовать в дальнейшем бизнес 4. В большой компании может требоваться принимать много решений и в ограниченный промежуток времени, а governance должен помогать в организации процесса принятия этих решений так, чтобы они были качественными. 5. Процессы governance - это дорогое удовольствие, но хорошая новость в том, что не требуется контролировать все принимаемые решения в организации, а плохая в том, что надо определиться с тем, а что нужно контролировать для получения хороших результатов 6. Здесь вступает в дело complexity, а точнее то, что мы работаем с complex adaptive system, у которых следующие интересные свойства - В них много взаимозависимых частей (люди, технологии, процессы, культура, ...) - Эти части меняют свое поведение динамически и адаптируются к изменениям (например, изменения в технологиях инфры приводить к изменению практик развертывания) 7. Люди хорошо адаптируются к изменениям в отличие от нашего существующего софта и они умеют принимать локально оптимальные решения, из которых вырастает со временем большая система 8. Если мы хотим влиять на поведение людей и принятие ими решений в нужную нам сторону, то мы не можем рубить с плеча и вот, что авторы книги рекомендуют делать

A big, up-front plan and execution approach to API governance is unlikely to work. Instead, you’ll need to “nudge” the system by making smaller changes and assessing their impact. It requires an approach of continuous adjustment and improvement, in the same way you might tend to a garden, pruning branches, planting seeds, and watering while continuously observing and adjusting your approach.

9. Для эффективного управления принятием решений стоит ответить на три вопроса - Какие решения надо менеджерить? - Кто и где должен принимать эти решения? - Как эта стратегия принятия решений повлияет на CAS (complex adaptive systems) 10. Вообще есть 2 концептуальных способа принятия решений: централизованный и децентрализованный. Их проще всего рассматривать через призму трех факторов - Доступность и точность информации для принятия решений - Талант к принятию решений - Стоимость координации 11. Другие важные аспекты для рассмотрения - это scope и scale - Scope of optimization - условно при децентрализованном принятии решений могут приниматься локально оптимальные решения и все будет выглядеть модно и инновационно. Но если учитывать только local scope, то на всю систему решения могут влиять негативно - дружить эти отдельные решения на уровне всей компании будет ой как тяжело - Scale of operations - это про количество решений, которые требуется принять. Условно, если требуется принимать сложные решения, то сложно обеспечить все децентрализованные команды профессионалами, что смогут их принять. А централизация принятия решений приведет центральную группу в бутылочное горлышко. Казалось бы, мы в тупике, но оказывается, что можно воспользоваться подходом разделяй и властвуй и организовать governance процесс через микс централизованного и децентрализованного подхода, но об этом в следующем посте. #Architecture #Software #Governance #Management #Leadership #Processes #Leadership

Третий раз в стационаре (Рубрика #LifeStory) В последнее время я начал получать фидбек, что больше историй из моей жизни разбавляют сухой контент канала с книгами, whitepapers и моими мыслями о работе. Я внял этой обратной связи и решил, что буду теперь периодически писать что-то из своей жизни и сегодня у меня есть о чем рассказать. Вчера я оказался в третий раз в своей жизни в стационаре, но первые два раза я был там сам, а вчера попал с сыном. Вообще, это длинная история: - В ноябре у него был отит, что мы вроде бы вылечили - В начале декабря мы сходили к лору из-за соплей и стало ясно, что у нас бинго: отит + воспаленные аденоиды - Мы решили, что надо оперировать, так как не хотелось уходить больными в Новый год - После операции, что должна была включать удаление аденоидов и операцию на ухе, ему нельзя бы было летать месяц - В итоге, у нас чуть не сорвался отпуск, но при операции выяснилось, что ухо прокалывать не пришлось - вода ушла сама - Удаление аденоидов приводило к запрету на полет в 2 недели, что позволило нам слетать в Шри Ланку, но средний и старший сын уже переиграли свои планы - Когда мы были в Шри Ланке у старшего сына (18 лет) были проблемы со здоровьем - оказалось, что он за неделю без лечения довел себя до пневмонии - В понедельник вечером мы прилетели в Москву, во вторник я сходил на работу, а вечером вторника жену и самого маленького сына накрыло болезнью - В среду я решил остаться поработать из дома, но приехавшие на дом врачи диагностировали отит у малыша, а также грипп у жены - эффекты были такие, что температура была у обоих в 38.5 градусов - Жене приехали ставить капельницу на дом, так как температура нурафеном не сбивалась, а я с малышом ближе к вечеру уехал в стационар, так как тоже температура была слишком высокой - В стационаре малышу и мне сделали тест на ковид - оказалось, что не он. Потом померили у врача температуру и сказали "сорок два", оказалось, что это было 40.2. - Получилось, что младший сын собрал страйк: отит с жидкостью, воспаленные мендалины и грипп, но зато теперь понятно как и чем лечить - капельницы проставили и температура пошла вниз В итоге, я вынес для себя следующее - Тянуть с врачами и анализами не стоит - Если лечение идет не по плану, даже в пределах одного дня, то стоит принимать меры - У меня нет контекста о детях - на все вопросы про прививки, алергии и болезни я запрашивал звонок жене и уточнял у нее, что показывает мою беспомощность в бытовых семейных вопросах - Моя жена делает много того, что очень важно, но воспринимается как данность, например, заботиться о здоровье всех в семье и только ее болезнь показывает что бывает, если она это не может делать #LifeStory #Storytelling

Measuring Developer Experience With a Longitudinal Survey - Part 2 (Рубрика #DevEx) Продолжая первый пост, расскажу про основные моменты в том, как устроены опросы про developer productivity в Google. 4) Основными фичами программы опросов в Google являются следующие моменты - Каждый квартал за программу опросов отвечает новая пара: исследователь и инженер. Исследователь отвечает за развитие и эволюцию программы исследований и коммуникации, инженер отвечает за автоматизацию инфраструктуры обработки и анализа данных. Сменяемость этой пары позволяет лучше задокументировать процесс и сделать его безпристрастным и повторяемы - Процесс проведения опросов четко описан и выстроен в формате пайплайна: определение изменений в опросах, имплементация изменений, верификация, запуск, анализ, подготовка и рассылка отчетов. - Процесс хорошо автоматизирован и большая часть его проходит без участия человека 5) Такой процесс помог иссследователям получать крутые инсайты, например - Какое было влияние пандемии COVID-19 на разработчиков в Google. Подробнее про это в моем разборе "Hybrid Productivity" - Как валидировать другие метрики, например, так ребята изучали поток, фокус и friction при разработке - подробнее про это в моем разборе "Measuring Flow, Focus, and Friction for Developers" - Как можно драматически улушить метрику, например, техдолг. Подробнее про это в моем разборе "Defining, measuring and managing technical debt" и в выпуске Research Insights Made Simple #2 с обсуждением этого whitepaper 6) Надо заниматься эволюцией опросов во времени, так как они имеют свойство удлиняться и может уменьшаться response rate. Авторы борятся с этим через 2 вещи - Sampling. Авторы бьют всех инженеров на три когорты, а каждая когорт проходит опросы раз в 3 квартала (условно каждый квартал только треть инженеров отвечает на вопросы). Важно, что группы именно 3, так как это позволяет отвечать им на вопросы в разное время года - Reporting. Авторы анонимизируют результаты и делают их доступными всем, а также показывают какие решения принимаются на их основе и к каким результатам они приводят. Это мотивирует инженеров их заполнять. 7) Последнее изменение опросов привело к тому, что авторы выкинули сильно специфические вопросы и сконцентрировались на тех, по которым можно принимать решения и отслеживать эффект

To better serve decisions at the company level, we opted for more generalizable questions focused on five outcome measures and four additional theme areas that are drivers of our outcomes

Основными outcomes являются: satisfaction, productivity, speed, ease, quality. А темы можно посмотреть в приложенном изображении 8.) Напоследок авторы дают алгоритм с рекомендациями для создания своей программы longitudinal survey

- Establish a clear and unique goal for your survey (ensure that there are no other survey programs or data sources that you can already use). - Collaborate with domain experts and researchers to develop an effective instrument. - Gather stakeholder buy-in (for example, communicate the value of survey data and partner with teams that can act on your results). - If you are planning to run a longitudinal survey, invest time in the beginning in setting up the right infrastructure, process, templates, and documentation. - Maintain the health of your survey program (control survey length and sample strategically). - Be transparent and accountable. The quality of your insights depends on the feedback provided by your developers, so make it clear why they should spend their time on it.

В общем, статья как обычно хорошо организована и достаточно практична - можно брать и использовать этот алгоритм в вашей компании, возможно стат значимых результатов как в Google относительно небольших эффектов от изменений вы и не заметите, но эффект от крупных изменений оценить сможете. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Measuring Developer Experience With a Longitudinal Survey - Part 1 (Рубрика #DevEx) Прочитал интересный whitepaper от ребят из Google, которые рассказали про свой метод проведения опросов для измерения опыта разработчиков. Это очередная статья из серии "Hunam centric approach to developer productivity" от ребят из Google, про которую я рассказывал раньше. А теперь основные моменты статьи 1) Авторы начинают рассказ с того, что они проводят такие опросы с 2018 года и именно поэтому это longitudinal survey, а в статье они поделятся основными выводами 2) Но начать стоит с того, а зачем вам может захотеть проводить такие опросы и они отвечают примерно так - Опросы изначально ориентированы на людей - задаются вопросы о том, как инженеры воспринимают, думают и чувствуют - Опросы быстрые и гибкие - их точно проще запустить и поменять, чем измерения, что основаны на логах из систем - Опросы могут дать данные о том, что невозможно объективно измерить, например, удовлетворенность, а также можно задавать открытые вопросы - Опросы можно быстро запустить для того, чтобы начать собирать данные о developer productivity 3) Конечно опросы многие критикуют, отмечая что - Опросы субъективны и их можно неверно интерпретировать - Они могут быть необъективными, особенно если респонденты заинтересованы в смещенных результатах - Они могут отображать стуацию как ее воспринимают люди, а не что происходит в реальности Авторы решают этим проблемы за счет совместного использования опросов и logs-based измерений, что дает более полную картину. Одновременно помогает долговременность проведения исследований - авторы могут показывать как меняется картинка по мере применения рекомендаций для улучшения ситуации Продолжение обзора в следующем посте. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Обложки и иллюстрации книг "Grokking Continuous Delivery" и "Грокаем continuous delivery"

Grokking Continuous Delivery (Грокаем continuous delivery) (Рубрика #DevEx) Одной из книг, что я прочел на новогодних каникулах стала книга Кристи Уилсон из Google про современные подходы к continuous delivery. Я достаточно осторожно отношусь к книгам из серии Grokking, но тут меня подкупило, что вступительное слово написало целых два крутых инженера, что точно умеют в инженерию - Джез Хамбл, что был соавтором книг "Continuous Delivery", "DevOps Handbook", "Accelerate" (я уже рассказывал про первую и третью книги из этого списка) - Эрик Брюэр, что сформулировал CAP теорему, а потом участвовал в разработке Google Spanner, а сейчас VP Infrastructure & Google Fellow Оба этих уважаемых джентельмена очень хорошо отзывались о книге во вступительном слове, поэтому я был в предвкушении интересного чтения ... и так и получилось. Но интересность была обусловлена не rocket science подходами, а скорее тем, как Кристи буквально с основ объяснила как выглядит разработка софта и зачем нужен continuous integrating, continuous delivery и чем он отличается от continuous deployment. По-факту, в книге 4 части, 13 глав и 2 приложения, которые чем-то напоминают мне комиксы - во многих главах разбираются почти реальные проблемы выдуманных компаний навроде "Cat Picture", "Super Game Console", "Ice Cream for All", "CoinExCompare" и так далее. Это позволяет автору продемонстировать эволюционное развитие подходов к инженерным процессам, а не сразу показывать идеальную картинку. Кстати, по оглавлению уже можно понять как выстроена логика повествования

Part 1: Introducing continuous delivery Chapter 1: Welcome to Grokking Continuous Delivery Chapter 2: A basic pipeline Part 2: Keeping software in a deliverable state Chapter 3: Version control is the only way to roll Chapter 4: Use linting effectively Chapter 5: Dealing with noisy tests Chapter 6: Speeding up slow test suites Chapter 7: Give the right signals at the right times Part 3: Making delivery easy Chapter 8: Easy delivery starts with version control Chapter 9: Building securely and reliably Chapter 10: Deploying confidently Part 4: CD design Chapter 11: Starter packs: From zero to CD Chapter 12: Scripts are code, too Chapter 13: Pipeline design

Из важного стоит отметить, что Кристи 1) Старается не привязываться к инструментам для CI/CD (для этого есть первое приложение, где рассматриваются их возможности) 2) Дает инструкции по настройке пайплайнов как для green-field, так и для brown-field проектов 3) Акцентирует внимание на лучших практиках: VCS как источник истины, безопасное развертывание с использованием автоматизации, использование шагов пайплайна для получения правильных сигналов о готовности софта для развертывания, отслеживание качества процесса поставки при помощи DORA метрик (подробнее про них в книге Accelerate, о которой я рассказывал в трех частях 1, 2 и 3) В общем, несмотря на мое глубокое погружение в тему книги, она даже мне принесла новые знания, а также систематизировала понимание. Я бы с большим удовольствием прочел ее в самом начале карьеры, чтобы сократить количество граблей, которые приходилось проходить самому:) Так что я очень ее рекомендую для тех, кто сейчас начинает свой путь в IT - лучше познакомиться с теорией о том, как должны выглядеть инженерные процессы из книги, чем пытаться самому прийти к ним на практике. Это точно сократить путь к становлению лучшим инженером. P.S. Книга на русском вышла в издательстве "Питер" и как по мне она переведена достаточно неплохо:) #Devops #Management #Leadership #Processes #SRE #Software #Devops #Architecture #SoftwareDevelopment

Новогодний отпуск Мой отпуск уже заканчивается, завтра на  работу, а сегодня еще 9 часов лета. Если подводить итоги, то отпуск в новогодние каникулы обычно бывает хорош и позволяет успеть многое: - Можно хорошо провести время с семьей и отдохнуть - Посмотреть красивые места - в этот раз это была Шри Ланка - Порефлексировать о  прошедшем годе и его итогах - Подумать о будущем - раньше я бы сказал о планировании, но сейчас предпочитаю не строить планы, а думать о приоритетах - Почитать интересные книги - я прочел тройку книг и несколько whitepapers В общем, отпуск удался, а завтра у меня уже будет первый рабочий день в новом году. P.S. И раз отпуск заканчивается, то дальше я смогу постить еще больше интересного в канале:)

What Do Developers Want From AI? (Рубрика #DevEx) Летом 2024 года вышла интересная статья про то, что эволюция AI - это поворотный момент, но с технологическими революциями, что меняют формат работы людей, человечество сталкивается не в первый раз. Поэтому авторы статьи решают провести параллели с развитием автомобильной промышленности и сфокусироваться на потребностях и целях наших разработчиков. Это статья из серии "Hunam centric approach to developer productivity" от ребят из Google, про которую я рассказывал раньше. А теперь основные моменты статьи 1) Последние достижения в AI привели к появлению большого количества инструментов разработки для поддержки искусственного интелекта (например, DuetAI, CoPilot и ChatGPT для задач программирования). После этого было проведено много исследований влияния этих инструментов на продуктивность разработчиков, где задавались вопросы навроде - Повышают ли улучшения ИИ скорость написания кода? - Улучшают ли они качество написанного кода? - Помогают ли они разработчикам находить более креативные решения? 2) Но вот обсуждений того, а как разработчики хотят взаимодействовать с AI в своих инструментах, было гораздо меньше. Авторы исследования со своим фокусом на человекоориентированный подход к пониманию продуктивности разработчиков решили это испраивать и провести исследование для ответа на вопрос, а где разработчики хотят видеть ИИ в своих рабочих процессах, и какими, по их мнению, будут его эффекты? 3) Здесь авторы начинают проводить параллели с автомобилями для понимания потребностей. Они говорят, что понимание того, что люди хотят и в чем нуждаются от технологий, является основой исследований пользовательского опыта. Однако этот подход иногда подвергается сомнению, особенно когда речь идет о крупных технических инновациях - в этих случаях вспоминают знаменитую фразу, приписываемуюГенри Форду: "Если бы я спросил людей, чего они хотят, они бы сказали 'более быстрых лошадей'". 4) Для исследования предпочтений разработчиков авторы провели многочисленные интервью и пользовательские сследования с разработчиками, имеющими различный опыт работы с инструментами разработки с поддержкой ИИ. Разработчики выражали свое желание, чтобы такие инструменты экономили их время и энергию, помогая им более эффективно выполнять свою работу, то есть они хотят, чтобы ИИ поддерживал более простые задачи и уменьшал рутину, позволяя им сосредоточиться на решении сложных проблем и творческих аспектах их работы. 5) Для того, чтобы понять какие области мешают разработчикам быть продуктивными в Google исследователи проводят опросы и анализируют логи. Это позволяет сфокусировать усилия на самых важных факторах, тройка которых в Google сейчас такая - Технический долг - Плохая или отсутствующая документация - Сложности в изучении новых платформ и технологий 6) Авторы классифицировали эволюцию улучшений AI по трем типам (проведя параллели с автомобильной промышленностью) - Улучшение существующих человеческих возможностей. Для машин это усилитель руля, антиблокировочная система для тормозов. Для AI в разработке это code completion. - Расширение человеческих возможностей (добавление новых). Для машин это камера заднего вида, контроль слепых зон. Для AI в разработке это code review suggestions, chatbots - Делегирование человеческих возможностей (фичи, что убирают human in the loop). Для машин это удержание полосы движения, автоматическое торможение, улучшенный круиз-контроль. Для AI в разработке это автоматический откат проблемных релизов, автоматическое удаление dead code, генерация тестов 7) Для успешного внедрения изменений с AI необходимо - Понимание сопротивления и скептицизма разработчиков - Создание правильной инфраструктуры для внедрения - Обеспечение безопасного и справедливого доступа во всех отраслях - Сохранение фокуса на целях разработчиков, а не только на технологических возможностях #Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

Обложки и немного иллюстраций к книгам "The Culture Map" и "Карта культурных различий"

The Culture Map (Карта культурных различий) (Рубрика #Management) Прочитал на каникулах этот бестселлер десятилетней давно от Erin Meyer и он мне понравился. В нем Эрин, профессор INSEAD, интересно изложила свою гипотезу о карте различий разных культур, которую можно воспринимать через восемь отдельных непрерывных шкал, включающих в себя 1. Communication (коммуникация): low-context vs. high-context 2. Evaluation (оценивание): direct vs. indirect negative feedback 3. Persuading (убеждениe): principles-first vs. applications-first 4. Leading (лидерство): egalitarian vs. hierarchical 5. Decision-making (принятие решений): consensual vs. top-down 6. Trust (доверие): task-based vs. relationship-based 7. Disagreement (несогласие): confrontational vs. avoidance 8. Scheduling (планирование времени): structured vs. flexible24 Школа мысли Эрин в том, что у каждой из этих шкал есть два экстремальных значения, а дальше каждая из стран позиционируется на шкале так, чтобы отображать медиану приемлемого поведения. Но важна не сама точка, а скорее относительное положение стран между собой, так как все познается в сравнении. Для этого автор щедро приводит очень большое количество примеров, разбирая каждую ось 1. Communication (коммуникация) - Низкоконтекстная - (США): Американский менеджер прямо скажет "Крайний срок проекта - следующая пятница, 17:00" - Высококонтекстная (Япония): Японский менеджер может сказать "Нам стоит подумать о завершении в ближайшее время", ожидая, что команда поймет подразумеваемую срочность. 2. Evaluation (оценивание - Прямая (Нидерланды): "Эта презентация полностью неверна и требует переделки". - Непрямая (США): "Вы сделали несколько интересных замечаний, но, возможно, стоит рассмотреть альтернативные подходы". 3. Persuading (убеждениe) - От принципов (Германия): Немецкий менеджер сначала объяснит теоретическую базу и методологию, прежде чем представить выводы. - От практики (США): Американский презентующий начнет с вывода или рекомендации, затем при необходимости предоставит подтверждающие данные. 4. Leading (лидерство) - Эгалитарное (Дания): Сотрудники свободно не соглашаются с начальником на встречах и могут пропускать иерархические уровни при общении. - Иерархическое (Китай): Сотрудники должны следовать proper каналам и получать одобрение непосредственного руководителя перед обращением к высшему руководству. 5. Decision-making (принятие решений) Консенсусное (Япония): Каждый отдел должен рассмотреть и одобрить предложение, прежде чем оно пойдет вверх по цепочке командования. Сверху вниз (Бразилия): Босс принимает решения самостоятельно, а члены команды должны выполнять их без вопросов. 6. Trust (доверие) На основе задач (США): Доверие строится через стабильное достижение результатов и соблюдение сроков. На основе отношений (Китай): Доверие развивается через совместные обеды, личные разговоры и построение социальных связей вне работы. 7. Disagreement (несогласие): Конфронтационное (Франция): Члены команды открыто дебатируют и оспаривают идеи друг друга во время встреч. Избегающее (Япония): Проблемы обсуждаются приватно в малых группах для поддержания гармонии и избегания публичной конфронтации. 8. Scheduling (планирование времени) Структурированное (Германия): Работа следует фиксированным графикам с четкими дедлайнами и точными временными рамками. Гибкое (Индия): Графики адаптируемы, с подвижными дедлайнами и регулируемым рабочим временем в зависимости от обстоятельств. В итоге, книга через модель и примеры помогает читателям взглянуть на другие культуры непредвзято и оценить какие недоразумения возникают из-за культурных различий, а не некомпетентности. Это позволяет преодолеть культурные границы и может помочь менеджеру мультикультурной команды - Определить потенциальные области конфликтов между культурами - Адаптировать стиль управления под конкретную культуру/культуры - Улучшить коммуникацию в международных командах P.S. Есть хороший обзор книги от Руслана Фазлыева, CEO Ecwid. #Management #Leadership #Culture #PopularScience

DevOps Metrics. Your biggest mistake might be collecting the wrong data (Рубрика #Management) Ради интереса я решил прочитать whitepaper шестилетней давности, в котором Nicole Forsgren и Mik Kersten рассказывали о devops метриках. Интересно, что статья начинается с цитат великих

“Software is eating the world.” —Marc Andreessen “You can't manage what you don't measure.” —Peter Drucker

А дальше начичнается погружение в эру digital и devops трансформаций и продажа разнообразным CIO рассказов о том, что организации зачастую не достигают целей IT из-за проблем со скоростью поставки программного обеспечения. И для того, чтобы улучшить эти процессы авторы предлагают поработать над созданием метрик, которые позволят обеспечить прозрачность и управляемость в этой области. Для этого они предлагают комбинировать 2 типа данных 1) System-based metrics Это метрики, которые строятся на основе данных из реальных систем. Например, данные о сборках, автотестах, релизах, работе в IDE и так далее. При рассмотрении этих данных требуется учесть аспекты - Completeness - достаточно ли полны данные, собранные из определенной системы для обеспечения той наглядности, метрик и отчетов, которые являются целью инициативы? - Comprehensiveness - достаточно ли данных собрано во всех системах для учета сквозной метрики, например, time-to-market? - Correctness - достаточно ли скоррелированы данные, чтобы быть правильными? Условно надо уметь матчить совпадающие данные из разных систем У этих метрик есть крутые преимущества - Precision - данные в системах создаются с большой точностью - Continuous visibility - данные из систем доступны в реальном времени, можно работать на потоке данных или анализировать их пост-фактум - Granularity - мы можем смотреть на данные из разных подсистем или компонент или наоборот подняться на уровень системы - Scalability - когда система сбора данных имплементирована, то ее можно растянуть на все продукты/проекты Но есть и сложности - Gaining a holistic view - во-первых сложно собрать данные со всех систем (нужен тулинг), а также из-за того, что у нас социо-технические системы, то нужна информация из глаз разработчиков о том, как работают инженерные процессы - Capturing drifts in the system - при изменениях в системах данные из них могут не обновляться, что дает неактуальную картину 2) Survey-based metrics Это метрики на основе проведения опросов о том, как работают процессы, системы или сами люди чувствуют себя:) У таких данных есть следующие важные аспекты - Cohesiveness - данные, полученные в ходе опросов, особенно хороши для предоставления полного и целостного представления о системах. - Correctness - разработка и измерение опросов является хорошо изученной дисциплиной, которую можно использовать для предоставления качественных данных и понимания систем и культуры. У этих метрик есть крутые преимущества - Accuracy при правильном сборе данных - A holistic view of the system - ответы, которые предоставляют респонденты, отражают их общее восприятие ситуации - Triangulation with system data - можно сочетать с системными данными - Capturing behavior outside of the system - Cultural or perceptual measures related to the system Но список недостатков тоже широк: точность данных не очень велика, получать данные постоянно невозможно (никто не будет заполнять опросы слишком часто), объем собранных данных (мало кто готов заполнять сложные опросы даже редко). А также если данные опросов используются для оценок, то ответы в опросах могут быть смещены в сторону ожиданий топ-менеджмента. В общем, по итогу авторы приходят к выводу, что комбинация двух подходов дает отличный эффект. Кстати, подробнее про развитие этой темы можно почитать в моем посте "Зачем заниматься темой developer productivity в большой компании" #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Обложка книги "Fundamentals of Enterprise Architecture" и немного иллюстраций. Забавно сравнить отличия финальной версии обложки и early preview.

Fundamentals of Enterprise Architecture (Рубрика #Architecture) Прочитал на каникулах книгу Tanu McCabe, что была посвящена корпоративной архитектуре и вышла квартал назад, а точнее в сентябре 2024 года. Мое мнение, что корпоративная архитектура - это удел корпораций, что сначала запускали devops трансформации, потом digital трансформации, а теперь все гонятся за AI. В общем, если у вас не технологическая компания, то enterprise architecture вам может и пригодится. В этой книге Tanu McCabe делает подход к снаряду, чтобы придать корпоративной архитектуре современный вид и теоретически у нее получается неплохо, но неясно как это стоит осуществлять на практике, хотя каждая глава сопровождается практически анекдотами, где приводятся примеры плохой реализации корпоративной архитектуры и хорошие варианты, что соответствуют современным тенденциям. И у нее достаточно неплохо это получается Если говорить про основные мысли книги, то они изложены в первой главе, где затрагиваются следующие моменты 1) Зачем нужна корпоративная архитектура? И автор отвечает, что она нужна для - Избегания изоляции отдельных частей организации (avoiding silos) - Избегания хаоса - здесь идет речь про борьбу с complexity через стандарты - Избегания технического долга, который мешает инновациям и бизнес гибкости Все три вещи выше являются признаками неэффективной корпоративной архитектуры, а вот эффективная помогает сформулировать технологическую стратегию на каждом уровне корпорации и помогает поставлять нужные решения 2) Автор описывает vision, mission, что должны быть у корп архитектуры и приводит generic примеры

The vision: Define technology strategy that transcends organizational differences to connect different aims into common business goals. The mission: Enable great architecture decisions to deliver great solutions as one team.

Читатели могут взять эти или придумать для себя сами. 3) Автор описывает функции корпоративной архитектуры, куда входят strategy, oversight, enablement, пересечение которых обеспечивает крутые архитектурные решения. - Стратегия помогает в достижении бизнес-целей организации - для этого важно про них знать - Enablement мне напоминает по описанию то, как компании создают платформы для поддержки работы своих компаний - Oversight включает в себя governance, risk, compliance 4) Автор рассказывает про роли архитекторов: enterprise, solution, software. Тут примерно то же самое, что я рассказывал 4 года назад в докладе "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения". Правда, у нас не было корпоративных архитекторов, а их роль лежит на технических директорах как мне кажется:) Эти ребята принимают решения разных volume и scope. 5) В принятии архитектурных решений помогают специализированные функции, что включают security, network, cloud, SRE, data, compliance и так далее. В общем, это похоже на привлечение центров экспертиз для принятия важных решений. 6) Бывают разные организационные модели: централизованная, федеративная и гибридная - В централизованной модели роль корпоративной архитектуры централизована и находится на уровне других топ-левел орг юнитов. - В федеративной модели роли распределена по отдельным доменам - В гибридной есть небольшая центральная часть, а основная часть федеративна 7) Автор описывает типичные архитектурные deliverables, что включают - Architecture decision deliverable - подробнее можно почитать здесь - Architecture pattern deliverable - это паттерн для решения типичной проблемы внутри организации, желательно с объяснением логики и примерами кода - Capability target architecture deliverable - это целевое описание группы возможностей, которое можно назвать архитектурным доменом. Про это интересно рассказать в отдельном посте - Application target architecture deliverable - это целевое описание архитектуры приложения В общем, книгу определенно интересно читать, она хорошо и логично написана, многое звучит хорошо, но не ясно как оно должно работать на практике:) #Architecture #Management #Leadership #Software

Enhancing Software Design and Developer Experience Via LLMs (Рубрика #ML) Иногда меня спрашивают почему я читаю whitepapers преимущественно от bigtech компаний. Обычно я говорю, что они обычно качественные. Но тут я решил дать шанс другой статье, а точнее "Enhancing Software Design and Developer Experience Via LLMs" с "ASE '24: Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering". Абстракт статьи звучит неплохо - Первоначальное внимание уделяется способности моделей понимать концепции дизайна высокого уровня - Впоследствии исследование переходит к расширенной генерации программных артефактов - В конце вводятся методы, специфичные для организации или задачи, для повышения производительности и опыта разработчиков программного обеспечения. Но если читать дальше, то складывается ощущение, что саму статью писал LLM:) И из всего плана исследования сделан только обзор работы LLMs для генерации кода. А дальше я расскажу подробности. Во введении идет речь, что сейчас LLM обычно дают подсказки уже после коммитов, а хотелось бы давать их или на ранних стадиях или в рантайме. Для этого автор рассказывает, что создание софта - это не только про написание кода и там есть еще куча этапов CI/CD. Поэтому план исследования выглядит так 1) Understand LLM - How LLMs handle code and natural language 2) LLM for software design (Plan-Code-Build-Test), где автор выделил фазы - Post commit. Identify problems and provide solutions - Pre-commit. Predict problems - Line level suggestion. Predict problems & provide hints while developers are working 3) ML Plugin. Develop a framework that can provide ML hints to developers 4) Generalize the framework. Apply the framework in other software development processes Интересно, что автор фокусируется на использовании в своих предсказаниях логов

This project aims to advance the analysis and utilization of logs geneated during software development and testing. By implementing real-time log analysis and auto-suggestion features, the research seeks to improve the post-test phase and provide actionable insights for future testing, simulation, and maintenance activities

Во второй части статьи автор рассказывает базу про трансформеры, а также приводится обзор других статей, что исследовали эффективность LLMs при разработке софта. В третьей части автор раскрывает карты и рассказывает про модель, которую он планирует использовать ... и это откопанная стюардесса, а точнее методология Model-Driven Architecture (MDA) от Object Management Group прямиком из начала двухтысячных. Сама методология предполагает использование трех шагов 1) Создание Platform-Independent Model (PIM) 2) Преобразование PIM в Platform-Specific Model (PSM) 3) И дальше генерация кода для выполнения Автор исследования стремится предоставить решения, специфичные для организации или задачи, адаптированные к различным контекстам компании, а также структуру, способную обобщать эти решения для более широкого применения в индустрии программного обеспечения. Чтобы достичь этого, автор планирует сначала разработать PIM на основе домена, а затем PSM, которые отражают конкретные настройки и требования различных компаний. Впоследствии можно усовершенствовать первоначальную PIM на основе отзывов от PSM, тем самым создав стандартизированную архитектурную структуру, которую можно будет использовать в будущих проектах внутри определенного домена. В четвертой части статьи авто рассказывает про то, как будет проиходить оценка работы моделей для PSM, где предплагается провести вычислительные эксперименты для предварительной обработки данных и оценки проектирования и процесса обучения модели. Это включает в себя файнтюнинг моделей и сравнение их производительности с другими предложенными моделями. В пятой части автор рассказывает, что из всего описанного пока готов только обзор использования LLM при написании кода:) P.S. В итоге, у нас whitepaper уровня курсовой работы студента, что он нагенерировал вместе с GPT-4 за пару вечеров - обзор нормальный, а все остальное в планах:) #AI #ML #Software

Developer Productivity for Humans, Part 8: Creativity in Software Engineering (Рубрика #Management) Продолжаю читать статьи от ребят из Google на тему продуктивности инженеров, а точнее в этот раз это статья про креативность. Я уже рассказывал про колонку про "Developer Productivity" в журнале IEEE. В этой статье авторы описываются свой подход примерно так: 1) Авторы исследования сделали обзор предыдущих статей и литературы и отметили, что креативность - это качество крутых инженеров 2) Но вот что значит креативность в software engineering - это большой вопрос, который авторы по привычке решили выяснить, начав с людей 3) Если кратко, то их выводы были в том, что креативность в разработке - это умное переиспользование, а не полная новизна, как принято в других сферах 4) Авторы проводили это исследование для того, чтобы понять как лучше измерять и поддреживать креативность инженеров - их интересует именно, что делает кретивным процесс разработки, а не какие персональные качества делают креативными конкретных инженеров 5) Свое исследование они решили сделать количественным, но поделили его на отдельные фазы - Feedback studies, когда обратную связь нужно было дать непосредственно, когда происходило определенное событие - Elicitation studies, когда нужно было сделать фотографию креативного момента раз в неделю (это мог был скриншот с сессии брейншторма, скриншот дизайн-документа, скриншот кода, который подвергся жестокому рефакторингу и так далее) - Follow-up interviews, когда исследователи задавали вопросы по фотографиям с воспоминаниями и просили инженеров описать в чем именно состояли моменты креативности - Post analysis, когда исследователи идентифицировали общие темы из собранных данных, такие как: повторное использование, инфраструктура, knhowledge sharing, обучение, новизна - Объединение полученных тем с конкретными моментами в developer workflow, которые помогли исследователям получить более глубокое понимание опыта участников исследований 6) В итоге, авторы выделили три ключевые темы, которые относятся к креативности - Коллаборация и брейншторминг взращивают креативность среди разработчиков - Problem solving с исследованием проблемной области через изучение и исследование создают сцену для креативности - Умное переиспользование и рекомбинация существующего кода полезным способом является основным атрибутом креативности в software engineering. Суть в том, что не надо быть новатором в коде, а лучше сделать решить сложную задачу простым и понятным способом, который потом будет легко поддерживать и развивать 7) Интересно, что авторы видят противоречие между продуктивностью и креативностью, когда чрезмерно фокусируясь на продуктивности не остается времени на креативные решения. Например, часто инженеры отмечали, что коллаборация с коллегами для решения сложной проблемы или сложный рефаторинг являются креативными, но редко когда такое менеджеры считают продуктивным:) Авторы формулируют гипотезу, что продуктивность - это про ближайшее время, а креативность про долговременный эффект от качественного кода. Напоследок авторы отмечают, что

There remains a need to better understand what creativity means in the context of software engineering, how it affects the whole software development process, and how factors like work location or AI tools might influence it.

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Processes #Creativity

Code of Leadership #27 - Интервью с Виктором Фирсовым про эволюцию развития веба Т-Банка за 12 лет (Рубрика #Management) В этом выпуске подкаста ко мне пришел Виктор Фирсов для того, чтобы обсудить как эволюционировали веб-интерфейсы Т-Банка и как он всеми силами помогал этому. Сейчас Виктор является техническом руководителем 100+ инженеров, что отвечают за публичный веб и личные кабинеты физических лиц. А начинал Витя с позиции инженера и занимался формами для привлечения клиентов. Эпизод доступен в Youtube, Podster, Yandex Music. На общение мы потратили чуть больше часа и успели обсудить следующие темы - Где Витя родился, учился и как попал в IT - Как он переехал из Нижнего Новгорода в Москву, приняв офер Т-Банка 12 лет назад - Как прошла технологическая трансформация при переходе со старого решения на react - Как команда росла и пришлось делать организационные изменения - Как выглядели вызовы в 2022-2023 годах и как их удалось с успехом преодолеть - Как выглядел проект ребрендинга в общем и что надо было сделать технической команде - Как вообще подходить к позиции технического руководителя и чем она отличается от инженерной - Какие советы можно дать вкатывающимся в IT, а также продолжающим свое профессиональное развитие В общем, выпуск получился очень плотный по темам, поэтому думаю, что вам не придется скучать при просмотре:) P.S. Я с Витей работаю 8 лет, с самого своего первого дня работы в компании и могу сказать, что он прошел большой путь от хорошего инженера до крутого технического руководителя. До последнего года он был моим прямым reportee и я как мог помогал этому случиться. В последний год он мой skip level reportee, но это ему не мешает показывать классные результаты. #Management #Leadership #Software #Processes #Retrospective #ChangeManagement

The elearning designer's handbook (E-learning. Пошаговое руководство по разработке электронного обучения) (Рубрика #Education) Эта книга Тима Слейда попалась мне на глаза случайно и хотя она рассказывает про создание онлайн курсов, но мне это показалось отчасти близким к написанию книги:) По-итогу, я прочел книгу за пару часов в силу ее небольших размеров и общей очевидности идей. Если рассказывать про книгу кратко, то она состоит из предисловия, вступления, пяти основных шагов и финального напутствия о том, что надо продолжать двигаться дальше. 1) Предисловие - здесь автор рассказывает про свой путь к педагогическому дизайнеру электронного обучения (я даже не знал, что это так называется до того, как прочел книгу). Тим изначально был subject matter expert много лет, а потом его попросили сделать курс для обучения других и ... так его карьера сделала поворот к созданию курсов 2) Вступление - здесь автор на пальцах показывает, что создание курса похоже на строительство дома. Он объясняет, что нужно понимание кто такие бизнес-заказчики, кто такие subject matter experts и зачем нужен план (чтобы дом достроился и был сдан, а не остался брошенным недостроем) 3) Шаг первый - создание плана проекта. По-факту, если вы знаете про проектное управление и руководили проектами, то тут вы не узнаете почти ничего нового. Автор рассказывает про то, что надо определиться со scope проекта, участниками, их зоной ответственнсти (лучше по матрице RACI, но он про это не говорит). Важно построить график проекта и отметить ключевые точки и контролировать их прохождение и так далее 4) Шаг второй - составление раскадровки курса. В этой части автор говорит о том, что лучше не делать курс целиком, а пользоваться методом прогрессивного JPEG, когда содержимое курса сначала набрасывается в черновом верхнеуровневом варианте, а дальше показывается стейкхолдерам. Это позволяет на начальном этапе провалидировать концепцию курса и получить ценную обратную связь. Этот этап позволяет задать канву курса и зафиксировать примерно материалы, что войдут в него. 5) Шаг третий - разработка курса. На этом шаге надо пойти и сделать сами материалы. Когда есть понятная канва и структура, то это должно быть не таким сложным делом. Главное сломать страх чистового листа и начинать работать над деталями курса по частям. 6) Шаг четвертый - проверка и контроль качества курса. Здесь автор рассказывает про базовые вопросы тестирования самого продукта, потом выкатку на бета-тестеров, а также проверку удобства получившегося продукта с точки зрения user experience через интервью с бета-тестерами 7) Шаг пятый - запуск курса. Автор говорит о том, что иногда курсы могут публиковаться в LMS системах, а иногда это просто html странички в интернете. В любом случае автору курса надо понимать на какой платформе он публикует курс, как он сможет его дорабатывать, а также где сможет посмотреть аналитику по прохождению курса учениками. В общем и целом, это очень базовая книга по созданию электронных курсов, у которой на английском вышло второе издание аж в 2020 году, а та версия, которую читал я, была издана на языке Шекспира в далеком 2018 году. Кажется, что с тех пор эта информация про создание курсов стала просто базой:) P.S. Кстати, у автора есть свой сайт TimSlade.com #Education #Writing

Over 3.1 million fake "stars" on GitHub projects used to boost rankings (Рубрика #Humor) Прочитал сегодня статью про накручивание рейтинга в GitHub. По-факту, здесь примерно та же проблема, что в других соцсетях, где популярност, лайики и ззвезды несут своим обладателям дополнительную ценность. В GitHub такой ценностью является то, что звезды воспринимаются как proxy метрика популярности проекта в коммьюнити и его дальнейшие перспективы. В середине декабря появилось исследование от Carnegie Mellon University, Socket Inc, North Carolina State University на эту тему. В нем ученые сначала разработали интструмент 'StarScout', который проанализировал 20 ТБ данных GitHub и первоначально обнаружил 4,5 миллиона подозрительных звезд от 1,32 миллиона аккаунтов. После фильтрации для повышения точности, окончательный подсчет показал 3,1 миллиона поддельных звезд от 278 000 аккаунтов в 15 835 репозиториях. Результаты исследования показывают, что проблема достигла пика в 2024 году, когда примерно 15,8% репозиториев, имевших более 50 звезд в июле 2024 года, были вовлечены в эти обманные практики. Эффективность инструмента обнаружения StarScout была подтверждена тем, что к октябрю 2024 года GitHub удалил 91% выявленных подозрительных репозиториев и 62% неаутентичных аккаунтов. Вот список находок авторов исследование

Research Question 1: How prevalent are fake stars in GitHub? 1) Fraudulent starring activities start to gain momentum in 2022 and have been surging since 2024. 2) Even a small portion of fake stargazers can greatly distort stars as a repository popularity signal. 3) Only a few repositories with fake star campaigns are published in package registries such as npm and PyPI. Even fewer are widely adopted. Research Question 2: What are the characteristics of GitHub repositories with fake star campaigns? 4) Most repositories with fake star campaigns are short-lived (only a few days of activity). 5) The majority of GitHub repositories with fake star campaigns seem related to pirated software, game cheats, and cryptocurrency bots. However, it is likely that they are actually malware clickbaits. Research Question 3: What are the characteristics of GitHub accounts that participated in fake star campaigns? 6) Compared to average GitHub users, accounts in fake star campaigns are slightly more likely to have an empty profile, but the differences are relatively small. 7) At least 60% of the accounts that participated in fake star campaigns have trivial activity patterns. Research Question 3: To what extent are fake stars effective in promoting the target GitHub repositories? 8) Buying fake stars may help a repository gain real attention in the short-term future (i.e., less than two months), but the effect is 3–4x smaller compared to real stars; it has a negative effect in the long term.

В итоге, имеем вывод, что звезды - это ненадежный сигнал для тех, кто практикует использование или контрибьют в open-source. Требуется использовать и другие сигналы, например из OpenSSF Scorecard, для которой есть отдельный whitepaper. #Software #Management

Стажировки в Т-Банк - Тинькофф Старт (Рубрика #HR) Открылась очередная зимняя программа стажировок в Т-Банк. Набор идет по куче направлений, в software engineering это направления вида java, scala, go, python, iOS, Android, .net, C++, а также SRE, ML, frontend и даже 1C:) Стажировки у нас оплачиваются и во время них вы будете работать над реальными задачами, у вас будет ментор, который поможет вам адаптироваться, а по итогам лучшие стажеры будут приглашены в штат компании. Стажироваться можно в рамках гибкого графика - от 20 часов в неделю, удаленно или в офисе, в России или в соседних странах (Беларусь, Казахстан). Для попадания на стажировку надо будет - Подать заявку и зарегестрироваться в личном кабинете нашей edu платформы - Заполнить анкету об опыте и мотивации, а также пройти экзамен - Пройти интервью с командами Если все пройдет успешно, то дальше останется только проявить себя во время стажировки, чтобы по ее окончании получить штатуную позицию. #Career #Software #Engineering