Эссе о разработке игр, мышлении и книгах

Два года пишем RFC — статистика

График количества RFC за два года

Два года как я Lead/Engineering Manager в платёжке Palta. А на следующей неделе я ухожу из компании в очередной творческий отпуск.

Время подводить итоги. Начну с моей самой любимой инициативы.

С первого месяца я начал продвигать идею предварения крупных изменений текстовыми документами — RFC — Request for Comments.

В этом посте будет анализ двух лет применения этой практики. Чтобы пошарить опыт, подвести итоги и иметь под рукой агитку для моего следующего места работы.

Далее

Эксперименты с Тарантогой закончены

Чтоб я ещё когда взялся делать blackboard мультиагентную систему с темпоральными свойствами :-D

В этом посте будет краткое подведение итогов, чтобы закрыть вопрос.

Заметок по ходу эксериментов я не делал, поэтому какие-то интересные детали рассказать сложно — в голове всё смешалось и затёрлось уже.

Далее

Пара слов о GitHub Сopilot

DALL-E: "Vrubel style painting of pair programming Robot + Human. An robot is writing code, a human is reviewing code".

DALL-E: "Vrubel style painting of pair programming Robot + Human. An robot is writing code, a human is reviewing code".

Последние несколько недель использовал GitHub Сopilot, благо для Emacs есть плагин. Поделюсь впечатлениями.

Для справки, я уже лет 15 осознанно не использовал умное автодополнение. Всё моё автодополнение — это DynamicAbbreviations, по сути — дополнение написанного слова на основе словаря из открытых исходников.

Причина отказа такая: используя «умное» автодополнение (например, подсказку аттрибутов/методов объекта) перестаёшь понимать проект. Начинаешь на автомате брать предлагаемые варианты методов/переменных, не разбираясь что они конкретно делают и есть ли альтернатинвые варианты.

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

С Copilot я, похоже, вернуcь к умному автодополнению, в его более правильном варианте.

Итак, давайте посмотрим чего умеет и не умеет Copilot.

Далее

Я и «умный» GUI в IDE

[Машина Голдберга](https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%88%D0%B8%D0%BD%D0%B0_%D0%93%D0%BE%D0%BB%D0%B4%D0%B1%D0%B5%D1%80%D0%B3%D0%B0)

Машина Голдберга

Updated: Этот пост написан до появления Copilot. Моё мнение о Copilot в отдельном посте.

В комментарии к модной типизации в Python мне обоснованно указали, что я не рассмотрел использование типов для помощи IDE. В частности, для автодополнения и подсказок.

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

Собственно году в 2010 я отказался от «умных» версий того же автодополнения и не жалею. В то же время, мои периодические порывы сменить Emacs на крутую современную IDE во многом вызваны как раз желанием проверить, не сделали ли наконец нормальный программистский CAD с действительно крутыми помощниками. Пока не сделали, так что сижу на Emacs :-)

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

На сколько я знаю, моя позиция не распространена, поэтому расскажу про её логику подробнее.

Далее

Системное мышление на практике

Спросили, использовал ли я системное мышление в реальной жизни и как оно мне помогло. А вот и не знаю, использовал ли :-)

Конечно знаю: использовал, помогло. Но чтобы ответить подробнее надо больше строк.

Есть несколько нюансов, которые усложняют ответ.

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

Во-вторых, «системное мышление», «системная инженерия» — это мемплексы — наборы мемов-практик. Если я использую 2 практики из 10 — я использую мемплекс? А если 51 из 100? Кто вообще определяет входит практика в мемплекс или нет?

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

Поэтому отвечу сразу для нескольких контекстов.

Далее