Мне было сегодня лет, когда я первый раз сделала squash в git-репозитории

...а пришлось этим заняться потому, что "автоматически выбирать подходящие переводы строк" в андроидном редакторе QuickEdit+ сошло с ума и перекроило файл на 13k строк

#пятничная_картинка

😎 -- понимаю
🤷 -- не понимаю
👍 -- не знаю, понимаю ли, но одобряю картинки

Лазейка для души

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

Мне нравится такой взгляд на вещи.

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

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

🧶🕸👻

#пятничная_картинка

😎 я сеньор с этой картинки
😱 я джун с этой картинки (или бывал им)
🤯 что все это вообще значит?

"У тебя там StackOverflowError не случится?" — Лена, объясни, как будто мне пять я специалист в какой-нибудь далекой от IT области, что это значит?

Рассказ получается трехэтажным.

Если буквально, то StackOverflowError — это отсылка к проблемной ситуации с компьютерами/программами, когда программа пытается использовать больше памяти из определенной области (стека), чем размер этой области позволяет. У этого бывают нежелательные последствия различной степени тяжести, включая очень тяжелые.

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

А именно:
🔹 есть контейнер (кастрюля / стек как кусок оперативной памяти компьютера)
🔹 есть содержимое, которое может подниматься и опускаться (молоко / данные, которые в стек попадают и уходят не произвольно, а "через верх стопки")
🔹 есть воздействие снаружи (нагревание / передача входных данных программе)
🔹 если воздействие слишком интенсивное и неконтролируемое — контейнер переполняется и содержимое переходит в пространство, для него не предназначенное (молоко заливает все вокруг / данные пытаются записаться в неправильную область)
🔹 в результате наступают нежелательные последствия (количество молока уменьшилось, вещи вокруг испачкались / программа упала сама или испортила данные других программ)

Так что вопросы про переполнение стека у людей я вижу структурно как "у тебя в голове молоко не перегреется и не убежит?"

Ну и на человеческом уровене читаю как заботу о том, чтобы не перегружать людей когнитивно

Ловушка совершенства

Продолжение к заметочке "Лазейка для души" (https://news.1rj.ru/str/WritingOnStickyNotes/181)

Отвечаю на вопрос: Лена, а каким идеальным вещам удавалось поймать тебя в ловушку? (И освободилась ли ты из нее?)

Вот такие примеры быстро приходят в голову:

🔹 Вязание крючком
Пока вязание идет строго по схеме — это приятно, но ощущается напряжение "надо продолжать супер-аккуратно следовать схеме". А когда замечаю, что что-нибудь перепутала или пропустила — расслабляюсь. В духе "ну... да. Перепутала. Но все равно красиво. И дальше тоже будет красиво"

🔹 Программный код, инструменты, устройство технических систем
Здесь я довольно капитально попадалась в западню очарования: "продуманный и подогнанный до деталек дизайн — привязанность — сохранить существующее устройство кажется важнее чем цель, которая достигалась инструментом"

🔹 Диаграммы, схемы
Если на встрече показывают аккуратненькую диаграмму — есть некоторый порог к тому, чтобы осмыслять ее критически или творчески. А стоит наклеить какой-нибудь первый стикер с вопросом, нарушить гладкость композиции — и процесс идет легче

🔹 А еще бывает "Лучше сделаю идеально, но никогда, чем как-нибудь, но сейчас", и это можно тоже увидеть как очарованность идеальным

Лена, расскажи главное про управление и планирование?

Свой опыт я бы суммировала так:

🔹 Учиться — полезно!
На меня самое сильное и практически-полезное впечатление произвели курс по управлению проектами по PMI, курс по фасилитации, и большой курс по гибкому управлению

🔹 Про управление вообще:
- думать командами, не отдельными специалистами
- управлять работой, не людьми
- визуализировать работу
- разделять рабочие встречи по смыслу
- научиться проводить (как минимум — различать) базовые встречи: планирование, дейли, демо, ретро, уточнение бэклога
- осознать и использовать шаблоны GROW/RGOW

🔹 Про планирование в частности:
- на каждом уровне детализации разделять цели и способы их достижения
- поддерживать живой бэклог
- декомпозировать (делить большое на маленькие кусочки)
- приоритизировать (сортировать по важности)
- фокусироваться (если начали, то заканчивать; не наращивать работу "в процессе")

🔹 Когда это все это на месте и работает — у меня появляется ощущение, что о разных штуках я могу не думать сама, а за меня "думают" процесс и артефакты-визуализации

В общем, научиться теории и развиться в человеко-документный гибрид 📚🧠📝

#пятничная_картинка

С людьми кстати так же

Человеческая инструкция vs. компьютерная программа

Однажды я писала для журнала Нож про работу программиста, и был у меня там пункт про дотошность:

А еще нужно быть дотошным: программы выполняются ровно так, как в них написано.

Это может быть непривычно и неожиданно по сравнению с тем, как выполняют просьбы люди.

Например, человеку можно сказать: «Сделай мне чаю» – и он сделает. Или скажет: «Чая в доме не осталось, давай лучше кофе».

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

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

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

Вовлеченная команда, зарисовка акварелью

Рисовала акварелью новогоднюю гирлянду (по видеоуроку), и увидела это как метафору работы руководителя.

А именно: в рисовании цветных лампочек и в организации работы команды похожее отношение между процессом и результатом.

Акварельный урок обещал результат: лампочки стеклянные, выпуклые, блестящие, светятся (и мне кажется, это получилось).

Процесс рисования обращал внимание совсем на другое: делаем пятно такой-то формы, темнее и краснее, добавить сепии, смягчить край, больше желтого. Нигде в процессе не было "сейчас сделаем выпуклость", "сейчас рисуем стеклянность", и тем не менее в конце ррраз -- и готова стеклянная выпуклая лампочка.

Понятно, что "стеклянность" и "выпуклость" влияли на процесс рисования, но не прямолинейно, не очевидным образом, иногда даже контринтуитивно.

В управлении командой хотим результат: активная самостоятельная команда, предсказуемая скорость, клёвые технические решения, довольные заказчики.

Процесс налаживания работы команды состоит из другого: завести регулярную встречу по уточнению бэклога, записать смысл каждой встречи, в начале встречи называть цель встречи, вести каждую встречу с использованием общего рабочего пространства, использовать визуализации работы, готовиться к ретроспективам и т.д.

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

Если брать терминологию теории систем, то вышенаписанное -- иллюстрация эмерджентности; и напоминание: мы строим систему ради ее эмерджентных свойств, но они на то и эмерджентные, что впрямую мы их не изготавливаем.

А если без специальной терминологии, то так: превратить "чего хотим достичь" в "какие действия выполнять" -- непростая задача; переход может оказаться совсем не очевидным и не соответствовать интуиции

Из старых заметок от подготовки к лекции:

Программирование начинается как веселая головоломка-приключение, продолжается падающими тестами и непонятными инструментами, а в конце мы читаем депрессивные отзывы пользователей.
Не забывайте смотреть на свой сервис и радоваться ему!

(Насколько помню, эту формулировку так и не использовала)

...