Коммуникация как сопромат для 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. Но цитату сейчас найти не могу :( Так что может быть и не эта книга, а пост в каком-нибудь блоге

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

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

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

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

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

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

Расскажу-покажу парадокс Симпсона
#статистика

Контекст: пытаемся статистически проверить влияние лекарства/процедуры/технологии/<чего-то еще>.

В симпсоновски-парадоксальном случае может показаться, что для каждой подгруппы проверяемое средство делает хуже, а для всей группы в целом — лучше.

Левшам хуже, правшам хуже, а всей группе целиком -- лучше 🤯

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

Пример!

В офис завезли новый кофе. Производители  заявляют, что от этого кофе разработчики делают меньше багов. Хотим проверить.

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

В контрольной группе 90 джуниоров, которые сделали 45 багов (50%) и 10 сеньоров, которые сделали 1 баг (10%). Общий процент баговых реализаций — (45+1)/100 = 46%

В экспериментальной группе 10 джуниров, которые сделали 6 багов (60%) и 90 сеньоров, которые сделали 10 багов (11%). Общий процент баговых реализаций — (6+10)/100 = 16%.

Если посмотреть на всех вместе, то багов стало в 3 раза меньше: 46% -> 16%. При этом и у джуниоров, и у сеньоров по отдельности багов стало больше: 50% -> 60%, 10%->11%.

Джуниорам хуже, сеньорам хуже, а группе целиком -- лучше 🤯

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

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

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

А если не можем... Это еще другая история.

Нельзя просто так делить одни числа на другие и называть это статистической проверкой ))

Комманд-лайновые гаммы
#command_line_magic

Понадобилось мне тут "транспонировать" текстовую табличку.

Исходный файл такого вида:

$ cat data.txt 
aaa | bbb | ccc
1 | 2 | 3

Две строки, в первой — названия полей через вертикальную черту, во второй — такое же количество значений (чисел), тоже через вертикальную черту.

Хочу получить такое:

aaa: 1
bbb: 2
ccc: 3

Каждое поле — на отдельной строчке. Имя, двоеточие, пробел, значение. Порядок — такой же, как в исходном файле.

В реальном файле полей было больше, несколько десятков, а значения — большие числа и числа со многими знаками после запятой.

Работа одноразовая, файл один, повторять не потребуется.

Кто как стал бы решать такую задачу? Приглашаю попробовать и может быть засечь время.

В следующем сообщении (https://news.1rj.ru/str/WritingOnStickyNotes/116) — пример данных, можно потестировать свои решения.

Мое решение — в комментариях

Пример данных к прошлому посту (https://news.1rj.ru/str/WritingOnStickyNotes/115), можно потестировать свои решения.

И мой вариант преобразования — в комментариях там же

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

Не то что я хорошо умею компьютеры...
Просто плохо умею сдаваться