[3/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx)

Продолжим рассмотрение статьи про developer productivity (1 и 2) обсуждение независимых переменных, а также построением самой модели.

Независимые переменные
Авторы взяли в качестве гипотезы 42 независимые переменные, которые по их мнению могли влиять на продуктивность. Эти 42 переменные схлопнулись до 39 после проверки на мультиколлинеарность. Эти данные были доступны из логов и результатов опросов. Все эти переменные были разбиты на 6 категорий
1) Code quality & technical debt - эти факторы связаны с качеством кода и техническим долгом, которые дальше разбираются в деталях. Кстати дальше авторы написали отдельные интересные статьи
- "Developer productivity for Humans, Part 7: Software Quality" - статья про качество, которую я уже разбирал
- "Defining, measuring and managing technical debt" - которую я разбирал с Димой Гаевским в подкасте Research Insights Made Simple, а также разбирал в отдельной статье
2) Infrastructure tools & support - здесь история про выбор инструментов, а также работу инфраструктуры. Часть из этих факторов были разобраны отдельно
- "Build Latency, Predictability, and Developer Productivity" - статья про важность не просто build time, а его предсказуемости и как это влияет на продуктивность, о которой я уже рассказывал
3) Team communication - здесь авторы говорят про коммуникации, дистанцию от менеджеров, код ревью. Кое-что авторы из этого разобрали в дальнейших статьях
- "Developer Productivity for Humans, Part 2: Hybrid Productivity" - это статья про то, как удаленная работа и удаленные коммуникации во время COVID повлияли на продуктивностьЯ рассказывал про нее раньше
- "Developer Productivity for Humans, Part 5: Onboarding and Ramp-Up" - это статья про то, как работает процесс онбординга и как на него повлиял COVID. Я рассказывал про нее раньше
4) Goals & priorities - это про ясность целей и про изменение приоритетов
5) Interruptions - здесь авторы замеряют влияние встреч
6) Organizational & process factors - проблемы из-за процессов, реорганизации и перемещения людей

Дальше авторы использовали квази-экспериментальный метод использования панельных данных для построения связи между воспринимаемой инженерами продуктивностью и независимыми переменными: 𝑦𝑖𝑡 =𝛼𝑖 +𝜆𝑡 +𝛽 * 𝐷𝑖𝑡 + 𝜖𝑖𝑡
Где
- 𝑦 - это самооценка продуктивности для инженера i в момент t
- 𝛼 - это независимые от времени необозреваемые параметры инженера, такие как образование или уровень навыков
- 𝜆 - это независимые от инженера эффекты от времени, например, изменение политики на всю компанию или сезонные эффекты (как январские каникулы в России)
- 𝐷𝑖𝑡 - это измеренные факторы продуктивности для инженера i в момент времени t
- 𝛽 - это причинно-следственныые эффекты факторов продуктивности 𝐷𝑖𝑡 в момент времени t
- 𝜖𝑖𝑡 - это ошибка во время t

Дальше авторы берут производную и получают формулу Δ𝑦𝑖𝑡 = Δ𝜆𝑡 + 𝛽 * Δ𝐷𝑖𝑡 + Δ𝜖𝑖𝑡 , где
- Δ𝜆𝑡 = 𝛾0 + 𝛾1 * 𝑇 и Δ означает разницу между соседними временными промежутками
- T - это категорийная переменная, что означает разницу между периодами
- после дифференцирования 𝛼𝑖 исчезает из уровнения, а Δ𝜆 можно явно контролировать, что говорит о том, что 𝛼𝑖 и 𝜆𝑡 не искажают результаты

Дальше авторы берут метод Feasible Generalized Least Squares (FGLS) и строят корреляции между зависимой и независимыми переменными и оценивают абсолютный эффект и статистическую значимость. Про результаты и ограничения исследования будет в последней части обзора.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Интервью с Глебом Михеевым про Individual Contributors, Site Reliability Engineering и надежность

Летом прошлого года мы записали выпуск подкаста "Фичи Катятся" с Глебом Михеевым, автором канала "Уставший техдир" (@tired_glebmikheev). Примерно в это время Глеб поменял работу и занялся AI-ассистентом в Сбере, поэтому снятое отправилось на полку. А сегодня Глеб опубликовал эту запись, где мы с ним много общались про развитие инженеров, проектирование систем, обеспечение их надежности и безопасности. В общем, за час мы успели обсудить много интересных тем. Вообще, мы часто с Глебом встречаемся на разнообразных конференциях и часто такие разговоры получаются очень насыщенными. Рад, что в этот раз мы записали такое общение на камеру:)

Сам выпуск доступен почти везде: ВК, Rutube, Spotify, Apple Podcast.

#Engineering #Software #Reliability #Architecture #Management #Processes #Leadership

Using Architectural Kata in Software Architecture Course: An Experience Report (Рубрика #Architecture)

Эта статья вышла летом 2023 и в ней Usman Nasir из Blekinge Institute of Technology (Швеция) рассказывал о своем опыте обучения студентов software architecture с использованием кат. Этот опыт основан на одном семинаре с катами на 20 студентов в рамках продвинутого курса по архитектуре. И хоть ничего нового в описании нет, но мне нравится сама идея использовать архитектурные ката при обучении студентов. Семинар по архитектурным ката был интегрирован в курс обучения как групповое упражнение, где студенты совместно участвовали в мероприятии, направленном на проектирование, документирование и оценку получившейся архитектуры.

В качестве задачек были взяты ката с сайта Ted Neward architecturalkatas.com, но были выбраны такие задачи, доменная область которых была легко понятна студентам, например, Check Your Work или Making The Grade. Сам семинар включал в себя
- Discussion & design phase - на этой фазе студенты изучали проблему, определяли архитектурные драйверы (нефункциональные требования, ограничения), а также дизайн решения, которое удовлетворяет требованиям
- Peer review & voting phase - на этой фазе студенты презентуют свои решения и оценивают работу друг друга, причем для оценок использовалась шкала
-- Nailed it: все ключевые функциональные требования закрыты и атрибуты качества учтены, а получившееся решение достижимо в плане реализации (feasible)
-- Missed a few things: в решении пропустили какие-то ключевые функциональные требованя или атрибуты качества
-- Missed it, badly: врешение пропушены ключевые функциональные требованя, атрибуты качества или сделаны большие неверные предположения при дизайне

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

В принципе, мне кажется, что проведение архитектурных ката - это хороший способ практического обучения
- Для студентов в универах это можно совместить с реальной реализацией предложенного решения на протяжении всего семестра
- Для инженеров в компаниях это можно совместить с воркшопом по проектированию спроектированного поверх возможностей, что есть в IDP (internal developer platform)

#Architecture #SystemDesign #Management #Engineering #Software #SoftwareArchitecture #Edu #Whitepaper

The Pragmatic Programmer: From Journeyman to Master (Программист-прагматик) (Рубрика #Engineering)

Достал тут очередную древнюю книгу с полки, чтобы вспомнить былое и рассказать как начинался для меня IT в начале 2000х годов. В этот раз речь пойдет про влиятельную книгу того времени, написанную Эндрю Хантом и Дэвидом Томасом в 1999. Основная мысль книги была о том, что программист должен быть прагматичным профессионалом, который постоянно совершенствуется, мыслит критически и ответственно относится к своему труду. Сейчас я бы сказал, что авторы пропагандируют здоровый инженерный подход, а не просто программирование. Интересно, что я уже рассказывал про книгу, но тогда фокусировался на своих записях из 2000х годов, а теперь решил поговорить про pragmatic programmer , ключевого персонажа, которого описывают авторы и который
- Заботится о качестве своего кода и принимает ответственность за свои решения (care about your craft) - ту есть отсылка к craft, а не engineering, в те времена были разные школы мысли о том, является ли программирование инженерной деятельностью или это скорее craftmanship (потом даже появился craftmanship manifesto для софта)
- Применяет принцип DRY (don't repeat yourself), избегая дублирования кода
- Использует автоматизацию для повышения эффективности разработки (automation)
- Регулярно тестирует код и применяет подходы вроде TDD (test-driven development)
- Постоянно обучается и адаптируется к изменениям технологий (по прошествии 25 лет я бы поставил этот пункт на первое место)
- Использует системы контроля версий (Version Control) как обязательную часть рабочего процесса
- Стремится к написанию понятного, легко поддерживаемого кода.
- Применяет техники отладки (debugging), такие как разговор с уточкой (rubber duck debugging)
- Следует принципам YAGNI ("You aren't gonna need it"), избегая излишней сложности
- Применяет подходы рефакторинга для улучшения структуры кода
В книге есть забавные истории про теорию разбитых окон ("broken windows theory"), о каменном супе ("stone soup") или супе из топора в русских сказках, а также метод отладки "резиновая уточка" ("rubber duck debugging").

Книга была издана чуть больше 25 лет назад и на тот момент она была чрезвычайно прогрессивной и новаторской - из описанного выше она ввела или популяризировала
- Принципы DRY, принци ортогональности (orthogonality) для декомпозиции системы на независимые компоненты (decoupling), важность рефакторинга
- Сфокусировала внимание на автоматизации процессов разработки и тестирования задолго до массового распространения CI/CD (Continuous Integration/Continuous Delivery) систем. Например, в то время многие компании не использовали даже VCS, не то что не писали тесты
- Сделала акцент на личной ответственности программиста за качество своего продукта, что было новаторским подходом на фоне тогдашних более формализованных методологий
- Предложила концепцию постоянного обучения и адаптации как неотъемлемой части профессионального роста разработчика задолго до того, как это стало общепринятым стандартом

P.S.
Интересно сравнивать то, что интересовало меня 20+ лет назад при прочтении книги и как я сейчас на нее смотрю с высоты опыта:)

#SelfDevelopment #Engineering #Software #SoftwareDevelopment #Management #Leadership

Программирование. Математические основы, средства, теория (Рубрика #Math)

Сегодня я решил вспомнить книгу Святослава Сергеевича Лаврова 2001 года издания, которая была выпущена в качестве фундаментального учебника по программированию. Автор был ученым, член-корреспондентом АН СССР и одним из пионеров советского программирования. Эта книга стала его последней работой. Честно говоря, я ее купил себе на первом курсе больше 20 лет назад и она мне тогда показалось сложноватой, но я честно пытался ее прочесть. Сейчас, пересматривая этот учебник, я понял почему она тогда показалась мне такой - автор решил в одной книге на 300 страниц дать основы математики и программирования, чтобы показать фундаментальную связь между этими дисциплинами. Зацените список дисцплин, что излогает автор в первой части с математическими основами
- Формальные языки и логические формальные теории
- Propositional and predicate logic
- Теория множеств, а заодно про графы и деревья
- Вероятности, немного про измерение информации и случайные процессы
- Теория вычислимости с lisp и Машиной Тьюринга
Каждая из этих тем тянет на отдельный семестровый курс, а то и больше:) И теперь, когда я пролистывал эту книгу, то мне все кажется достаточно понятным, а 20+ лет назад все казалось не таким ясным
Во второй части автор переходит к основным понятиям и конструкциям языков программирования, где все начинается с дружелюбного использования формы Бэкуса — Наура для описания синтаксиса языка, дальше продолжается описанием структур данных, структуры действий, работы с процедурами, а дальше новыми веяниями в виде объектно-ориентированного и функционального программирования.
В третьей части речь идет про анализ свойств программ, где автор рассказывает про оценку сложности алгоритмов, доказательство свойств программ, формализацию семантики языков программирования и так далее.

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

P.S.
А тем, кто интересуется основами программирования, но хочет почитать про них в научно-популярном формате, я рекомендую книгу "Код: тайный язык информатики" ("Code: The Hidden Language of Computer Hardware and Software"), про которую я уже рассказывал. У нее, кстати, относительно недавно вышло второе издание.

#Math #Engineering #Software

Обложка книги "Программирование. Математические основы, средства, теория"

Вдруг что-то важное - Как учиться с помощью AI, развивать технические скиллы и причем тут адаптивность (Рубрика #SelfDevelopment)

Появился выпуск подкаста "Вдруг что-то важное", куда я пришел в качестве гостя, чтобы поговорить про обучение и адаптивность.
Ведущими эпизода были:
- Андрей Смирнов, организатор конференции Soft Weekend и подкастер
- Ульяна Батуева, тимлид PR-отдела в KODE
А обсуждали мы тему постоянных изменений - вокруг меняется все: фреймворки, методологии, инструменты, тренды… Как писал Льюис Кэролл в своей Алисе "Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!". Но такая погоня легко может привести к выгоранию. В выпуске мы попробовали обсудить как найти баланс, как научиться адаптироваться к изменениям осознанно, без стресса и паники, как использовать AI для обучения и не утонуть в потоке информации.

По-моему, выпуск получился достаточно интересным, хотя не уверен, что я сам знаю ответы на вопросы, представленные выше:)

#Management #SelfDevelopment #Edu #AI #Leadership #Software

[4/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx)

Закончим рассмотрение статьи про developer productivity (1, 2 и 3) и обсудим полученные авторами результаты.

Топ пять факторов, что получились после анализа содержали следующие факторы
- Project code quality (качество кода в проекте)
- Hindrance of shifting priorities (препятствия в изменении приоритетов)
- Technical debt in projects (технический долг в проектах)
- Innovation of infrastructure & tools (инновации в инфраструктуре и инструментах)
- Overall satisfaction with infra & tools (общая удовлетворенность инфраструктурой и инструментами)

Дальше авторы применили панельный анализ с запаздыванием. Суть в том, что они получили корреляцию между продуктивностью инженеров и факторами, что приведены выше, а хотелось бы получить более сильные результаты и понять направление связи. Для этого они выдвинули две гипотезы
1) QaP: изменения в качестве кода в момент T-1 коррелирует с изменениями в продуктивности инженеров во времени T. В виде формулы это выглядело так: Δ𝑃𝑖𝑡 = 𝛼 + 𝛽Δ𝑄𝑖𝑡−1 + Δ𝜖𝑖𝑡
2) PaQ: изменения в продуктивность в момент T-1 коррелирует с изменениями в качестве кода в момент T. В виде формулы это выглядело так: Δ𝑄𝑖𝑡 = 𝛼 + 𝛽Δ𝑃𝑖𝑡−1 + Δ𝜖𝑖𝑡
Оказалось, что первая гипотеза о том, что рост качества кода связан с повышением производительности подтверждается со следующей силой

We found that a 100% increase of satisfaction rating with project code quality (i.e. going from a rating of ‘Very dissatisfied’ to ‘Very sat- isfied’) at time T-1 was associated with a 10% decrease of median active coding time per CL, a 12% decrease of median wall-clock time from creating to mailing a CL, and a 22% decrease of median wall-clock time from submitting to deploying a CL at time T.

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

Отдельно надо рассказать про опасности для валидности этого эксперимента, которые описали авторы. Их всего 4
1) Content. Авторы измеряли продуктивность по ответу на один вопрос в проводимом EngSat опросе, что конечно не дает полной картины. Например, авторы отмечают, что этот вопрос был про индивидуальную продуктивность инженера, а не про эффективность команды. Примерно также не все факторы, что могут влиять на продуктивность были рассмотрены
2) Construct. Восприятие вопроса про продуктивность могло отличаться у респондентов. Например, кто-то мог думать о продуктивности в формате нафигачить быстро фичу, а кто-то учитывал разницу в качестве при создании фичи. Ну и там был еще ряд мест, где респонденты по разному могли воспринять сами вопросы
3) Internal. В этом исследовании авторы используют панельный анализ с запаздыванием, что эффективно предполагает, что эффекты на индивидуальных инженеров не зависят от времени. Например, у одного инженера сменился проект и команда, другому достался крутой ментов, у третьего что-то случилось в семье. Одновременно, могли бы быть проблемы, если какие-то категории инженеров систематически не участвовали в опросе, например, ветераны разработки или наоборот новички. Но авторы такие отклонения контролировали.
4) External. Весь эксперимент основывает только на опыте инженеров внутри Google, а значит может не иметь обобщающей силы на другие компании в индустрии.

Несмотря на все потенциальные проблемы, мне понравилось это исследование не только итоговым ответом на вопрос про то, что улучшает developer productivity в Google, но и самой методологией проведения эксперимента.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes