Бургер за спортзал: противоречия поощрений

С поощрениями себя (за соблюдение распорядка, за сделанные дела) есть сложность.

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

А если награда -- что-то субъективно полезное (яблоко, красивый ежедневник, почитать интересную книгу), то тоже противоречиво: к отсутствию желаемого поведения добавляем еще отказ от радости.
Человек заслуживает есть яблоки, вести красивые ежедневники и читать интересные книги при любых условиях, а не только если Очень Хорошо Себя Ведет.

И как быть?

Я нашла для себя несколько стратегий поощрений, свободных от противоречий, формулирую:

* "кофе со вкусом триумфа"
* "токен успеха"
* "выставка достижений"

"Кофе со вкусом триумфа" -- это что-то приятное, приемлемое в любое время, с добавлением мыслей про проделанную работу. "Я здорово справилась, и теперь пойду за триумфальным кофе". Я пью кофе и просто так, но триумфальный -- особенный. Вместо кофе может быть и яблоко, и книга, и ежедневник.

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

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

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

Магия командной строки

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

Командная строка -- это изящная и мощная концепция, и владение CLI-инструментами делает жизнь проще в самых разных ситуациях.

Чтобы оконкретить все эти похвалы -- "изящная", "мощная", "проще", "разные" -- собираюсь под тегом #command_line_magic постить примеры, когда я думала "как же хорошо, что у нас есть командная строка". Посмотрим, что соберется.

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

Смысл командной строки не в том, чтобы их отменить, а в том, чтобы к любому сценарию с любой программой добавить новых возможностей.
Кстати, постараюсь поскорее написать пример, как командная строка помогла в сценарии с Miro (витруальная доска и стикеры).

Командная строка: легко передавать и выполнять инструкции
#command_line_magic

Команды в командной строке -- это текст. Их можно копировать и отправлять почтой и мессенджерами. А потом копировать, вставлять в терминал, нажимать Enter и радоваться результату.

Примеры из жизни: инструкции для графической программы и для тековых конфигов.

Вот объясняла в текстовых сообщениях, как в Android отключить обновление приложений через мобильный интернет:
* заходи в приложение Play Store (гугловая программа, откуда устанавливаешь другие программы)
* справа вверху должен быть твой портрет в кружочке, или инициалы -- нажимай туда
* вылезет окошко, в нем выбирай Settings (Настройки, иконка -- шестеренка)
* там будет раздел Network (по-русски наверное Сеть), нажимай
* там будет пункт Auto-update apps (по-русски что-то про автообновление), нажимай
* там выбирай Don't autoupdate или Over Wi-Fi only (Выключить автообновление или Только через Wi-Fi)
* нажимай Done (Готово)
* нажимай на центральную нижнюю кнопку
* готово!

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

А текстовые команды? Копируешь, вставляешь, выполняешь.

Вот однажды писала в мессенджере, как временно закомментировать регулярные задачи, относящиеся к конкретному шарду БД:

(подразумевается ssh на серверы, выполняющие задачи)
sed '/shard.12/s/^/#/' -i /etc/cron.d/*

На одной стороне -- copy-paste, send, на другой -- copy-paste, Enter

Или вот обсуждали настройки buffer pool в нескольких шардах:

(подразумевается рабочая копия репозитория с конфигами)
cd .../mysql-conf
sed -i 's/innodb_buffer_pool_size.*/innodb_buffer_pool_size   = 150G/' shard1.cnf shard2.cnf shard3.cnf shard4.cnf dict.cnf
sed -i 's/innodb_buffer_pool_size.*/innodb_buffer_pool_size   = 80G/' monitor.cnf

Или вот разбирались с ssh:
добавь в файл ~/.ssh/config строчку IdentityFile ~/.ssh/id_ecdsa

Или вот инструкция по предварительной настройке для перенаправления X11 через ssh (X11 forwarding):
на клиентской стороне добавьте строчку ForwardX11 yes в файл ~/.ssh/config
На сервере добавьте строчку ForwardX11 yes в файл /etc/ssh/sshd_config и перезапустите sshd.

copy-paste, copy-paste, copy-paste

После вчерашнего поста получила в личке комментарий: "вот видно, что ты пользуешься GNU sed-ом, и что сервера у тебя линуксовые".
Дедукция, круто! ✨

Еще про инструкции и про левшей

Я много лет использовала компьютерную мышку "под левую руку".

Сложность с леворукой мышкой: все инструкции и туториалы говорят "нажмите левую кнопку мыши", "нажмите правую кнопку", а у меня кнопки наоборот.

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

Сейчас я держу мышку под правой рукой, но "правым-левым" кнопкам все равно не доверяю и мысленно перевожу в "главная-другая".

И из этого рассказа становится понятно, что я не пользователь макбуков и эпплокомпьютеров ))

Коммуникация как сопромат для IT-шника

Табуретки и компьютерные программы -- чем отличаются? Программу нельзя потрогать. Она никакого цвета, никакого веса, никакого объема. Для написания программы неважны физические свойства материалов.

Удельный вес, прочность на изгиб и на сжатие, теплопроводность и твердость по Моосу -- ничего такого не требуется принимать в расчет ни для hello world, ни для большой социальной сети или видеохостинга. (Конечно, речь про софтовую часть сервисов. Чтобы построить датацентр для серверов, сопромат нужен, как и для любой другой стройки.)

Но не бывает же совсем без ограничений? Если не физическими свойствами веществ, значит, изготовление IT-продуктов ограничено чем-то другим? Чем?

Наполовину шутка, но наполовину серьезно: программистский сопромат -- это коммуникация.

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

А какое главное свойство, которое нужно для успешной коммуникации в IT-командах?

Мой нынешний фаворит -- терпение.

С одной стороны, обыкновенное бытовое терпение: никогда не торопиться бить тарелки, уметь спокойно разбираться в напряженных разговорах.

А с другой -- терпение волшебное профессиональное: уметь не удовлетворяться первым быстрым ответом/решением/планом.
Иметь настойчивость и выдержку продолжать и продолжать разговор, пока у участников не включится медленное мышление, которое система 2 у Канемана.

Командная строка + Miro

#command_line_magic

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

В Miro выделяем карточки -- большим прямоугольником, без разбора. Копируем (Ctrl-C).
В терминале запускаем команду
cat |grep '^ *[0-9]* *$' |xargs echo |sed 's/ / + /g' |bc -l
Вставляем скопированное, и потом Ctrl-D.

Готово, получили сумму.

Дотошный читатель может заметить, что cat в начале команды и -l в bc необязательны.
Это правда, что без них тоже будет работать.
Но "избыточный" вариант лично мне написать проще и быстрее: срабатывают готовые блоки-ассоциации, о которых уже не надо задумываться в деталях. Это хороший размен.

А в примере на картинке сумма получилась ровно 100.

Командная строка не стареет

#command_line_magic

В прошлой заметке я показывала, как с помощью cli-инструментов посчитать сумму чисел на карточках из Miro.

А знаете что еще интересно? Если заменить Miro на какой-нибудь irc, то рецепт сработал бы даже 43 года назад.

cat |grep '^ *[0-9]* *$' |xargs echo |sed 's/ / + /g' |bc -l

Представляете? Сорок лет назад все это уже работало.

Рассказываю подробнее хронологию.

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

Вот что находится:

cat -- 1972 год
* https://www.freebsd.org/cgi/man.cgi?query=cat&apropos=0&sektion=1&manpath=FreeBSD+13.1-RELEASE+and+Ports&arch=default&format=html говорит "A cat utility appeared in Version 1 AT&T UNIX."
* UNIX V1 -- это 1972 год, см. например https://gunkies.org/wiki/UNIX_First_Edition
* man cat из v1: http://man.cat-v.org/unix-1st/1/cat, датирован 3 ноября 1971 года

grep -- 1975 год
* https://www.freebsd.org/cgi/man.cgi?query=grep&apropos=0&sektion=1&manpath=FreeBSD+13.1-RELEASE+and+Ports&arch=default&format=html говорит "The grep command first appeared in Version 6 AT&T UNIX."
* Unix v6 вышла в мае 1975 года, см. например Википедию https://en.wikipedia.org/wiki/Version_6_Unix
* man grep из V6: http://man.cat-v.org/unix-6th/1/grep

xargs -- 1977 год
* https://www.freebsd.org/cgi/man.cgi?query=xargs&apropos=0&sektion=1&manpath=FreeBSD+13.1-RELEASE+and+Ports&arch=default&format=html говорит "The xargs utility appeared in PWB UNIX."
* Мануал от PWB UNIX 1.0 датирован маем 1977 года: https://archive.org/stream/pwbunixusersmanualedition1.0/PWB%20UNIX%20User%27s%20Manual%2C%20Edition%201.0_djvu.txt, и там уже есть xargs

echo -- 1972 год
* https://www.freebsd.org/cgi/man.cgi?query=echo&apropos=0&sektion=1&manpath=FreeBSD+13.1-RELEASE+and+Ports&arch=default&format=html говорит "The echo command appeared in Version 2 AT&T UNIX."
* UNIX V2 -- это 1972 год, https://gunkies.org/wiki/UNIX_Second_Edition
* man echo из UNIX V2: http://squoze.net/UNIX/v2man/man1/echo, дата -- 15 марта 1972 года

sed -- 1979 год
* https://www.freebsd.org/cgi/man.cgi?query=sed&apropos=0&sektion=1&manpath=FreeBSD+13.1-RELEASE+and+Ports&arch=default&format=html говорит "A sed command, written by L. E. McMahon, appeared in Version 7 AT&T UNIX."
* UNIX V7 -- это 1979 год, https://gunkies.org/wiki/Unix_Seventh_Edition
* man sed из V7, к сожалению без даты: http://man.cat-v.org/unix_7th/1/sed

bc -- не позже 1975 года
* неожиданно man из FreeBSD не говорит ничего про историю: https://www.freebsd.org/cgi/man.cgi?query=bc&apropos=0&sektion=1&manpath=FreeBSD+13.1-RELEASE+and+Ports&arch=default&format=html
* в V1 (1972 год) нет bc, но есть dc http://man.cat-v.org/unix-1st/1/dc
* V2 (1972 год) -- аналогично http://squoze.net/UNIX/v2man/man1/dc
* V3 (1973 год) -- тоже нет http://squoze.net/UNIX/v3man/man1/
* V4 (1973 год) -- тоже нет http://squoze.net/UNIX/v4man/man1/
* V5 (1974 год) -- тоже нет http://squoze.net/UNIX/v5man/man1/
* и наконец в V6 (1975 год) bc уже есть http://man.cat-v.org/unix-6th/1/bc

Итак, самые старые комнды из нашего рецепта -- cat и echo -- существуют уже больше 50 лет, с 1972 года. Самая молодая команда -- sed -- с 1979 года.

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

Принятие невозможного

В заметке "15 самых полезных навыков в IT" я записала такое: "Принимать невозможное и все-таки работать с ним", https://blog.liruoko.ru/ru/2022-11/top-skills/#accept_impossible

Это важный навык, но хитрый, ускользающий.

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

Поэтому!
Пользуясь случаем привожу пример прямо изнутри невозможного.

Вот сейчас наблюдаю (немного со стороны, но близко) такое: с помощью одной и той же библиотеки две разных программы делают одинаковый PUT http-запрос к одному и тому же API. В одном случае все нормально, а в другом вместо PUT запроса в API приходит GET.

🤯 По-чем-му? Не-мо-жет-быть!

Опять о профдеформации для марафона #пиши_публикуй_Агментек

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

На одном курсе дали задание "напишите эссе про <что-то там полезное>". У меня получилось 10 списков, сгруппированных в несколько категорий и разделов; в сумме примерно тысяча слов. И только когда смотрела на ответы товарищей по курсу, подумала что "эссе" скорее подразумевает гладкий текст, а не список с точками-звездочками.

Письмо списками — то, чего я почти не делала 15 лет назад и все время делаю сейчас.

А на картинке — надпись краской на заборе:
Вещи, которые я ненавижу:
1. Вандализм
2. Ирония
3. Списки

Марафон #пиши_публикуй_Агментек подсказывает написать что-нибудь на тему: Как моя работа влияет на жизнь людей вокруг и человечество в целом (мои конкретные действия и вся моя сфера деятельности)

Моя сфера деятельности. Как влияет IT на жизнь людей вокруг? Вступать в перечисление в духе "заказ пиццы через интернет, комьпьютерная томография, самоуправляющиеся автомобили, мессенджеры и мемы, скопления персональных данных, Mariner 1, Therac-25" — как-то банально. Но! у Макса Дорофеева на следующей неделе будет стрим про влияние IT на все остальное, и там думаю будет интересно: https://news.1rj.ru/str/mnogosdelal/373

Что-нибудь небанальное про IT в жизни? Я вот недавно узнала, что когда меняют шины на автомобилях, потом делают компьютерно-обогащенную балансировку колес.

Мои действия. Как то, что непосредственно я делаю на работе, влияет на людей вокруг? Хотела бы я знать. Могу привести пример в обратную сторону: на мою карьеру существенное влияние оказал один товарищ по факультету, просто фактом своей работы в компании. "Он может, значит и я наверное смогу", и я решилась отправить резюме, за которым потянулось все-все-все остальное.

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

Итого вопрос про влияние тянет за собой или что-то совсем огромное, или что-то совсем непонятное. Если найду интересную серединку -- напишу еще

На тему "Зачем работа" мне еще обычно вспоминается песня Bruttosozialprodukt группы Geier Sturzflug.

Это задорная сатирическая песня из 1970-х годов; рефреном в ней повторяется "сейчас поплюем на руки и пойдем повышать ВВП".

Перевод слов на анлийский есть тут: https://lyricstranslate.com/ru/bruttosozialprodukt-gross-national-product.html , на русский тут: https://teksty-pesenok.ru/geier-sturzflug/tekst-pesni-bruttosozialprodukt/605026/

Я узнала про эту песню из книги The Power of a Single Number: A Political History of GDP. Книга про то, как ВВП стал главной метрикой в экономике. В предисловии автор пишет (перевод чуть ниже):

▶️
Popular culture shows just how strongly statistical denotation of economic power can shape the consciousness of an entire country, such as Germany. How else can one explain that, in 1983, a relatively unknown band called Geier Sturzflug (Vulture's Nosedive) managed to land a number one hit single for several weeks in a row, noscriptd, quite unromantically, "Bruttosozialprodukt"-"Gross National Product"? The song's refrain, which most Germans still know well enough to sing along to, goes, "Ja, jetzt wird wieder in die Hände gespuckt / Wir steigern das Bruttosozialprodukt" (Now let's get down to work / Let's boost the gross national product). Even if the song was meant ironically and hit the charts during a period of high unemployment, it is a telling indication of the high status German society attaches to the benchmark.
/
Популярная культура показывает, насколько сильно статистическое определение экономической мощи может формировать сознание целой страны, такой как Германия. Как еще можно объяснить, что в 1983 году относительно неизвестная группа под названием Geier Sturzflug несколько недель подряд занимала первую строчку в хит-парадах с песней под довольно неромантичным названием «Bruttosozialprodukt» — «Валовый внутренний продукт»? Припев песни, который большинство немцев до сих пор знают достаточно хорошо, чтобы подпевать, звучит так: «Ja, jetzt wird wieder in die Hände gespuckt / Wir steigern das Bruttosozialprodukt» (Давайте приступим к работе / Давайте увеличим ВВП). Даже если песня была задумана с иронией и попала в чарты в период высокой безработицы, это красноречивое свидетельство того высокого статуса, который немецкое общество придает этому показателю.
⏹

Каким-то образом этот пассаж мне кажется даже забавнее, чем текст самой песни.

Про сообщества экспертов
для #пиши_публикуй_Агментек

"Сообщество экспертов" -- это, по мне, люди:

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

Что мне от сообщества? Помощь (ответы на вопросы), вдохновение (расширение горизонтов, что-то совсем новенькое), возможность поделиться успехами с теми, кто понимает.

Что сообществу от меня? Надеюсь, то же самое.

Главные сообщества у меня?

Когда-то давно -- мир Perl-программистов. Большой источник вдохновения. Особенно мне нравились маленькие локальные конференции. Скучаю.

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

Выпускники курсов Better Life. Хронологически самое позднее, зато богатое на "найти ответ на насущный управленческий вопрос".

Желаю всем найти свою экспертность, а с ней и сообщество.

И закончился второй марафон #пиши_публикуй_Агментек

Получилось тихо и незаметно.

В порядке итогов — топ-3 постов, про которые я рада, что их написала за эти два месяца (не все напрямую в ответ на марафонные темы, но ассоциации-ассоциации):

🔹 https://news.1rj.ru/str/WritingOnStickyNotes/103 — смешная песня про валовый внутренний продукт и серьезная и от этого тоже смешная цитата про образ этого самого валового внутреннего продукта в поп-культуре

🔹 https://news.1rj.ru/str/WritingOnStickyNotes/100 — про принятие невозможного. Продолжение обещала, продолжение будет

🔹 https://news.1rj.ru/str/WritingOnStickyNotes/91 — "ловушка обобщения проблемы". Обещала еще лонгрид на эту тему, по-прежнему обещаю

Математика и мониторинги, из недавнего рабочего обсуждения

📝 У математиков есть поговорочка: "математик знаменит своими некрасивыми доказательствами".

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

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

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

📟 Со сложной бизнес-логикой, мониторингами на нее и документацией на то и другое -- похоже. Запрограммировать логику и мониторинги и задокументировать их хоть как-нибудь -- это одна активность. Упростить документацию, сделать все относительно легко постигаемым для коллег, которые не участвовали в исходной разработке -- другая. Нужны обе.

"Двухпроходная" работа по документированию/объяснению -- это нормально, не надо из-за этого переживать и огорчаться

Командная строка и Телеграм

#command_line_magic

Если что-то можно превратить в текстовый файл — с этим немедленно можно сделать что-нибудь интересное или полезное с помощью command-line инструментов.

Например: история чата в Телеграме (меня обычно интересуют Saved Messages).

Историю можно скачать как текстовый json-файл: менюшка в чате, Export chat history, Format: machine-readable json.

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

Вариант менее требовательный к установленным программам, но и чуть менее аккуратный:

cat result.json|grep '"date":' |sed -e 's/.* "//' -e 's/^\([0-9]*-[0-9]*\).*/\1/' |sort |uniq -c

Вариант с программой jq, аккуратный:

cat result.json |jq '.messages|.[].date' |sed -e 's/"//' -e 's/^\([0-9]*-[0-9]*\).*/\1/' |sort |uniq -c

Если хотеть еще большей аккуратности, можно год-месяц выбирать не регулярным выражением, а по-честному распарсить дату через date -d
Но для быстрой статистики "Когда сколько сообщений было" хватает и регулярного выражения

Продуктовый подход к <почти чему угодно>, моя концептуализация

В последние пару лет мне стало интересно понемногу накапливать теорию про продуктовый дизайн.

Самая яркая-новая мысль, которую я выловила: продуктом можно считать кучу разных вещей.

Например: работу; дом; вообще устройство жизни; хобби и т.д.

А если все это продукты, то и подходы-инструменты-фреймворки одни и те же.

На картинке — моя концептуализация "из чего состоит продуктовый подход", состояние "на сейчас".

Картинка в большем разрешении и чуть более подробный текст живут тут: https://blog.liruoko.ru/ru/2023-02/anything-as-a-product/

Асимметрия везения и невезения, квази-цитата

Года полтора назад прочитала примерно такое про везение и невезение:

▶️
(В проектах по разработке программного обеспечения) счастливые и несчастливые случайности вполне могут просходить с одинаковой частотой.

Но! Есть разница в том, как они действуют.

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

Пример: я хочу в субботу как можно раньше приехать из Москвы в Петушки. Я знаю, что первая электричка уходит в 6:17 и прибывает в 9:04. Происходит удачное: в субботу назначают дополнительную электричку в 4:36. Если я заранее посмотрю расписание, замечу новую электричку и успею на вокзал -- в 7:16 я буду уже в Петушках, и скажу "повезло". Но я могу не посмотреть, не заметить или не успеть, и везение пройдет мимо.

В разработке аналогично. Заказчик подумает, что часть фич не нужна; соседний проект отложат и освободится еще одна команда; в команде найдется классный эксперт как раз в нужной области. Если это заметить, быть готовым, и использовать, то проекту повезло. Если не замечать, не быть готовым, не использовать -- в проекте будут только несчастливые случайности.
⏹

И про источник. Я была довольнь сильно уверена, что прочитала такое в книге "Time Predictions: Understanding and Avoiding Unrealism in Project Planning and Everyday Life", авторы Torleif Halkjelsvik, Magne Jørgensen. Но цитату сейчас найти не могу :( Так что может быть и не эта книга, а пост в каком-нибудь блоге

Тикеты от людей и алерты от машин -- одно и то же или разное?

На днях столкнулась с вопросом: (в проекте по разработке и поддержке веб-сервиса) разбирать жалобы от пользователей и разбирать срабатывания автоматических алертов в продакшене -- это одна и та же работа или разные?

Казалось бы, и то и другое -- сигнал о проблеме в сервисе; какая разница, каков источник сигнала?

Тем не менее, мне кажется, что это разные работы, хотя развернутые аргументы привести пока не готова.

А еще тут есть второй этаж: а почему собственно полезно ответить на этот вопрос?
-- Для оптимизации усилий. Если работы разные -- возможно, их надо выполнять разными специалистами. По крайней мере, не смешивать оба вида работ в одних руках в одно время. Если работы разные -- у одного человека могут быть в них разные квалификации. Может быть, это снова ведет к разделению ответственности между разными специалистами. И наверняка разным работам требуется разное обучение.

Если все это аккуратно учесть, то напрягаться можно будет поменьше, а результаты получать побольше