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

Мы с женой не можем решить, какое основное блюдо сделать на Новый Год.
Решили, что будем действовать концептуально: сделаем пиццы, на каждой из которых названия всех ингредиентов начинаются с одной буквы. Пока придумали две: с ананасами, анчоусами и аливками и с онанасами, ончоусами и оливками.
Предлагайте ваши идеи!

Уже традиционно итоги года писать я не буду 😁

Зато поделюсь впечатлениями от программирования. Я перед новым годом брал отпуск и пару дней потратил на то, чтобы написать бота, который будет учитывать наши расходы (дожили до той стадии, когда уже надо).
Писал на питоне, использовал telebot. Вот из документации его очень сложно вывести аннотации типов для своей программы. Да и в целом интерфейс, сделанный на декораторах, выглядит несколько убого ИМХО. НО! Зато всё работает, очень легко разобраться, как добавить функциональность, все работает, как ожидаешь. Просто код сложновато сделать читаемым (но более или менее получилось).

Второй кусок это тупейший парсер, который умеет понимать всякое там "2UsD на врагов отечества вчера" и "+ 1 rUb зарплата"/"100500 кофе". Я его вообще-то написал по TDD. Но, честно говоря, получилась ужаснейшая лапша. Зато я оценил мощь встроенных в питон функций для работы со строками.

Третий кусочек оказался самым сложным. И ещё более всратым, чем два предыдущих. Бот пишет все транзакции в гугл табличку. Чтобы начать писать в гугл таблички, нужно, блин, завести и настроить аккаунт в гугл клауд! Традиционно отвратительный UX от гугловского облака я преодолевал по трём докам. Потому что не существует какой-то одной доки, а инструкции в интернете от тех, кто делал это полгода назад, уже не работают, потому что гугл опять переделал весь UI. Ну им виднее, они дорого стоят.
В целом норм, когда уже настроил. Даже лимиты такие, что можно небольшой стартап крутить (5рпс на операцию, емнип). Но API сделан в худших традициях работы с базами данных. Там текстом набиваются магические команды (нет, не sql), а потом они кормятся в какой-то билдер, который традиционно заполняет параметры переданными значениями и шлёт батчом по сети куда-то там в недра гугла.
Справедливости ради я в доках есть примеры (которые не работают, конечно же), которые можно слегка потюнить и использовать, не вдаваясь в детали того, что там написано. Я справился, короче.

Программировать мне понравилось, бот работает исправно (захостил его в яндекс облаке), интерфейсы, как и раньше, говно, TDD не спасает от лапши в коде, а питон всё ещё неплохо описывается тем самым мемом.

Всех с новым годом! И удачных интерфейсов вам!

Ещё утром посмотрел вот это видео. Пушка-бомба, маст си 🐉.
Канал вообще топовый, но местами сложноватый. А вот конкретно это видео супер помогает укладывать в голове многие вещи, если вы вдруг, как я, учите южно-славянские языки.

Почему так? Церковно-славянский язык — это язык Кирилла и Мефодия (очень грубо), как раз-таки из южно-славянской группы, с примесью греческого. Поэтому часто говорят, что он очень похож на болгарский. Раскрою тайну века: он и на сербский похож.
Язык для Руси, по-сути, письменный, но оказавший заметное влияние на русский. Всё-таки, в церковь слушать проповеди (или че там читают) ходили все. Есть у слов церковно-славянского языка оттенок старины в русском: врата, перси, град, злато (я думаю, что именно поэтому Илиада в переводе Гнедича именно такая). Но кроме этого ещё такой пафос, возвышенность. А оно не старое, точнее, не совсем старое, оно просто вообще другое, слово это, из другого языка. У меня домофон и сегодня говорит: "врата отворе".

Посмотрите, короче. Сможете очень душно объяснить ребёнку, что Деда Мраз это просто очень возвышенное название Деда Мороза.

Книжки для тимлидов

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

"Руководство командой разработчиков программного обеспечения" С. Архипенков
До четвертой главы, я просто не мог понять, как такую книгу вообще мог кто-то издать и тем более советовать!
Книга начинается с того, что автор рассказывает, какая есть крутая штука — соционика. Рассказывает, что существует ещё MBTI. И что обе эти штуки суть расширенная Юнговская классификация.
Очень интересно, за вычетом того, что эти классификации — полная херня (уж простите за Панчина, но этот видос правда хороший).
Дальше срываются покровы! В современном мире старые методы управления не работают, а программисты это такие особенные творческие снежинки, с которыми нужно работать очень специальным образом. И вообще большинство программистов автором записываются в две какие-то там (очень близкие) категории по своим психотипам.

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

Прошу обратить внимание, что я говорю именно о ВВЕДЕНИИ в темы. Там очень небольшая глубина и околонулевая ширина рассмотрения этих вопросов.
Книга очень маленькая, поэтому ожидать от неё иного было бы странно.

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

"Как пасти котов" Дж. Рейнвотер
Собственно, предыдущая книга рекомендовалась, как альтернатива книге "Как пасти котов". Буду называть её КПК, потому что это смешно.
Так вот, КПК вроде как нужно перестать рекомендовать молодым тимлидам, потому что она устарела.
Про устарела — несомненно. В книге много внимания уделяется работе с бумагами, ведению электронного документооборота в кастомных приложениях, как-будто нет устоявшихся в индустрии методологий разработки (на самом деле они упоминаются в самом конце книги, но все предыдущие главы игнорируют их существование), нет представления о таск-трекерах.
В общем, есть, что выбросить. Рекомендую так и делать при чтении этой книги. Если вам стало понятно, что это какая-то устаревшая фигня, то смело пропускайте главу целиком.

Однако на мой взгляд эта книга гораздо более полная и полезная, чем предыдущая. Здесь автор тоже делит сотрудников на какие-то типы (это вообще все руководители делают, будет пост про это), но здесь это не ядро его работы. Программисты в этой книге тоже особенные, но коты, а не снежинки. Это существенно. Потому что не загоняет людей определённой профессии в узкие рамки каких-то психотипов.
Очень много внимания здесь уделяется техническому лидерству. Есть глава про отношения со своим начальником. Сквозная тема книги — лидерство.

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

👇👇👇

👆👆👆👆

"FAST менеджмент" Ф. Нестеров
Это не совсем про тимлидов. Эта книга для любых руководителей. И она мне всё ещё нравится больше всех. Возможно, дело в том, что я там её больше двух лет назад, но я так не думаю.
Вот вы же мне и советовали вместо этой книги почитать КПК. Я прочитал, теперь советую вам обратно: всё-таки читайте fast менеджемент.

Эта книга намного шире двух предыдущих. Она включает в себя все существенные аспекты _управления_, о которых сказано в предыдущих двух книгах. А ещё добавляет такие важные темы как: работа со смежниками, рост самого руководителя, ситуативное руководство, как устроены коммерческие компании, зачем нужны разные отделы, модель жизненного цикла Адизеса.
Тоже есть классификация сотрудников по типам, даже своя собственная.

В этой книге есть довольно много рецептов. Они очень общие, но есть примеры. Это позволяет очень сильно успокоиться при вступлении в новую должность. Кроме того, именно эта книга максимально откровенна из всех трёх. Это помогает быстро схватить ориентиры и цели, метрики успеха, на которые нужно ориентироваться на руководящей позиции.

Вывод: в книге нет особенностей IT, и вообще она несколько про ex-СНГ, говорят (хотя я не нашел противоречий с той же КПК).
Но однозначно маст рид!

Про деление людей на типы

Я заметил, что очень многие руководители делят сотрудников на типы. Чаще всего выбирают какие-то четыре. Некоторые берут нетленную классику Гиппократа холерик-сангвиник-флегматик-меланхолик. Другие выбирают DISC. Третьи придумывают своё: ТУКО Нестерова или классы Вастрика.

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

Мне самому нравится DISC, но не как классификатор людей, а как учение о том, что все люди разные. Не хорошие и плохие, не воспитанные и невежи, не грубияны и льстецы. А просто люди, которые по-разному коммуницируют. Очень часто не так, как ты.
Это знание позволяет перестать всех мерить по себе (хоть это и важный приём эмпатии, но он примитивен). Например, если с тобой говорят грубо и прямолинейно, это еще не значит, что человек хам. Просто он так чувствует, убирает "лишнюю" мишуру из потока информации.

С другой стороны, если посмотреть на модель Вастрика или ТУКО, то можно в ней найти всех своих коллег и себя. Прямо как с гороскопами 😈.

В чём проблема этих классификаций?
1. Человек в течение времени перетекает между категориями
2. Скорее всего человек не разделится чётко между категориями

Все эти классификации основываются на каких-то шкалах. Например, всё по плану vs разберемся на ходу.
Ну мы с вами тут в теорвере (и здравом смысле) сильны, знаем, что по ЦПТ здесь будет скорее всего нормальное распределение с медианой где-то посередине между экстремумами этих шкал. Давайте считать выраженными различия, которые сильнее хотят бы одной сигмы. Таких людей, с выраженными отличиями, будет 30%. Для каждой шкалы. При делении на четыре типа шкалы обычно тоже четыре. Выраженное отличие хотя бы по одной из школ получат только 75% людей. А если шкалы две, то вообще только половина.
Вероятность же получить выраженное отличие по всем четырём шкалам — меньше 1%. Кто хочет перепроверить, смотрите биномиальное распределение.

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

Что уж говорить о соционике и MBTI! Там вообще 16 групп.

Тем не менее надо отметить, что Панчин в своём ролике упоминает статью в Nature, где действительно эмпирически на огромной выборке в 1.5М человек обнаружились четыре кластера людей по результатам опросника по пяти шкалам.

Впрочем, это нам никак не помогает.

Моё мнение такое. Модели типов сотрудников полезны, как ментальные модели. Но нужно помнить, что они достаточно слабые и нестабильные.
У меня в работе вообще не получается их использовать. Слишком сложно для меня это.
Гораздо проще узнать у самих людей, чего они хотят и к чему стремятся. Подмечать, как им комфортно работать. Терпеть и замещать собой недостающие роли.

Здесь нужно срочно заспойлерить моё непопулярное мнение из подкаста javaswag.

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

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

Объясняю

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

2. Теория ограничений говорит нам следующие вещи: в производственной цепочке всегда есть узкое горлышко, constraint; накопление запасов вредит прибыльности производства.

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

Пока constraint свою часть работы не сделает, фича в продакшен не поедет. Но в погоне за сторипойнтами и велосити продуктовые скрам команды об этом не думают, просто фигачат фичи во весь опор.
Имеем, что есть некий код, который не приносит прибыли (не работает в проде), но
- замедляет ci (больше компилировать и тестировать)
- усложняет разработку (надо не сломать, когда пишешь следующую фичу, поправить больше тестов)
- усложняет чтение кода (его тупо больше)
- создаёт иллюзию того, что работа готова (скорее всего, когда инфра сделает свою часть, здесь будут ошибки на интеграции, устаревшие вызовы, идентификаторы и другие потоки данных)
- деньги на эту разработку уже потрачены (разработчикам заплатили зарплату, тесты жрут электричество, в продакшене жирный бинарь хуже перформит, роняя метрики)
Вот это и есть те самые запасы по Элияху.

Собирая всё это вместе, понимаем, что лучше бы вообще ничего не делали, чем фигачили код впрок, "на будущее". Моё непопулярное мнение именно об этом.

Но можно лучше. Вспоминаем снова про армию, которая не должна бездельничать. Пусть чистит ружья и точит пилу.
Вместо фичей впрок нужно сосредоточиться на задачах, которые не зависят от работы команд constraint-ов, а лучше вообще от других команд не зависят. Это
- тот самый тех долг
- метрики, алерты, observability
- производительность
- доступность, надёжность
- качество, баги
Все эти вещи полезны для компании. А ещё важно, что они не вредны, т.к. не создают "запасы на складах".
Эти задачи будут приносить компании деньги, а не наоборот.
А разработчики будут счастливы, потому что НАКОНЕЦ-ТО им дали время на тех долг. Тот редкий случай, когда ситуация win-win.
Подумайте об этом.

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

Очень душные большие посты (как вы любите)
Разбавлю мемом

Про тех долг

Что есть тех долг и как с ним работать?
Большинство программистов неправильно считают тех долгом плохо написанные куски кода. Типа некрасивые, костыльные решения.
На самом деле деле тех долг это те решения в коде, которые замедляют и усложняют твою работу.
То есть если ты смотришь на уродский кусок кода, который меняется (или тем более читается) раз в полгода — это не тех долг. А вот если у тебя есть кусочек, который бесит тебя при решении каждой пятой задачки, то это как раз хороший кандидат в тех долг.

Если что-то не мешает или мешает очень редко (и ещё сила эффекта важна, конечно), то оно "кушать не просит", деньги вы не теряете или теряете очень мало. Переписывать такой кусок экономически не целесообразно.
А вот что-то такое, что увеличивает время решения каждой следующей задачи — это долг. В прямом смысле. Вы _должны_ переписать этот кусок. А пока не переписали, платите проценты. Причём буквально. Затраты на разработку растут. Такие штуки нужно чинить.

Об этом есть хороший, хоть и относительно старый доклад.

Об последовательное выполнение задач

В книге tameflow есть длинная телега на тему не надо делать несколько задач одновременно. Это объясняется сменами контекста. Что если ты переключился между задачами, а потом вернулся к уже начатой, то нужно сначала вспомнить, что ж там было, и где ты остановился. Сюда еще накладываются встречи, которые разрывают день и всё становится совсем плохо.

Сейчас читаю Дорофеевские Джедайские техники. Там во второй же главе тоже рекомендуется делать одну задачу в единицу времени, т.е. не держать несколько задач начатыми одновременно. Но объяснение с другого ракурса.
Если ты получаешь задачи строго по очереди: одну получил, сделал, получил следующую, то делаешь 10 задач в неделю. Если у тебя сейчас две задачи, одну ты закончил и сразу же получил следующую, то есть у тебя всегда две задачи, то делаешь ты их всё так же последовательно, но теперь тратишь своё мыслетопливо на приоритезацию, планирование и переживания. В итоге в неделю делаешь уже восемь таких задач, а не десять. А если таких задач одновременно пять? Всё становится ещё хуже.

Результаты в обеих ментальных моделях получаются одинаковые: чем меньше параллельно задач делает человек, тем эффективнее он это делает. Это, кстати, относится не только к людям, но и к командам.

Отсюда, несколько я знаю, выросли WIP лимиты канбана. У них есть несколько серьёзных проблем, о которых как-нибудь в другой раз, но суть они передают хорошо.

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

Это я к чему? Если хотите стать эффективнее (как IC или как тимлид), то нужно принять тот факт, что процессор в голове однопоточный (sic!). И стараться делать задачки по очереди. Теория ограничений не зря одним из основных постулатов имеет ненакопоение запасов.
А Дорофеев эту неэкономию масштаба (так и называется) подрезал у Ройса из Software Project Management: A Unified Framework

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

Всегда, когда думаю о профессиональном развитии, смотрю в том числе на собеседования. Мне кажется, они стараются концентрированно отразить всю суть работы по профессии. Ну знаете, джавистов почти наверное спросят про concurrency, а плюсовика почти наверное не спросят (разве что на очень сеньорные позиции).

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

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

Вот я принёс вам пост от Насти Абрашитовой. Как нанимает она. В том числе тимлидов (я, например, тимлидов не нанимаю). Интересно.
https://t.iss.one/tealmead/118

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

ЕТО СТАРАСТЬ

Во, хрестоматийный пример того, о чём я тут затираю. Посмотрите всего одну минуту (можно дольше, это не вредно). Там тимлид как раз рассказывает, что у него бэки всю работу сделали, фронты ещё даже не близко, и совершенно не понятно, чем занять бэков, если только вдруг нет техдолга в бэклоге.
В качестве решения почему-то предлагается нанимать фулстеков. Хотя на самом деле это не сработает. Просто переместит куда-то констрейнт. То есть проблему _внутри_ команды он уже видит и распознает (это взаимодействие подсистем). А вот подумать о надсистемах, о _наруже_ уже забыл. Получится ситуация "у меня на лужайке всё хорошо, а что у соседа дом горит, так это его проблемы".
Здесь нужно не делать локальную оптимизацию, а ухватиться за найденный констрейнт и его прокачивать, через него регулировать скорость. Вот о чём я говорю.

Про тех дизайны

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

В теймфлоу задачи должны двигаться по статусам только слева направо. Если они застревают в ожидании — это плохо, это повод для эскалации вплоть до топов. А уж если произошёл переход назад — очень плохо.
Если коротко, то это объясняется тем, что задачи должны делаться строго по порядку, а приоритет у них по cost of delay. Если задача застряла, то вы теряете деньги (это самая дорогая в терминах простоя задача по определению). Если задача вернулась в один из предыдущих статусов, то она могла оказаться позади менее приоритетной или даже провести к тому, что теперь в работе слишком много задач — теряем фрупут.

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

Первое, что нужно сделать: хорошие описания задач. Garbage in — garbage out, как у нас говорят. Нужно заставить постановщика задачи писать как минимум definition of done. А желательно ещё объяснить зачем это делается и как мы проверим, что сделано так, как ожидалось.

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

Вводим дизайн ревью! Теперь ДО кода нужно написать, _как_ ты планируешь решать задачу. Примерно по предложению или два на день работы. Написал, просишь кого-то посмотреть и идёшь писать код, не дожидаясь вердикта. В процессе дизайн ревью могут возникать дискуссии, новые варианты, плюсы и минусы. Дизайн будет меняться, пока не получит ок от ревьюера. Некоторые считают, что теперь код ревью уже в принципе можно не делать (смотрите Шароватова и Дельгядо). Мы делаем. Но это теперь происходит очень быстро. Прочитав слова в дизайн документе, понимаешь, куда смотреть в ПРе. Понимаешь, что хотел сказать автор. На деле обычно достаточно сверить, что код соответствует дизайну.

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

Но ведь эта бюрократия увеличивает латенси задачи: появляется новая стадия, надо что-то писать словами, надо что-то читать, насколько это плохо?
Ни на сколько. Фрупут на самом деле растёт за счёт пропажи флоубеков. Джиттер (волатильность латенси) падает. Более того, если у вас дизайн вылезет до самой длинной стадии (например, до написания кода или код ревью — у кого как, надо замерять), то вы даже уменьшите латенси за счёт того, что задачи с написанным дизайном можно передавать от разработчика к разработчику.
А ещё у нас остаются артефакты, по которым можно понять, как и почему принимались такие решения в коде.

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

Про отношение к работе

Некоторые знают, что я люблю пурпурные шен пуэры. Они непопулярны, многими считаются за брак, а потому их довольно редко встретишь. И вот как-то во время пандемии познакомился я в твиттере с чуваком из Питера, который торговал чаем. Нигде, из привычных мне мест, пурпурного шена не было. И тут он мне и говорит: "А у меня есть!".
Закралось ко мне в душу сомнение, грешен. Но я заказал блинчик пурпурного и ещё всякого понемногу. Потом оказалось, что чего-то из моего заказа прям нет, но можно заменить другим... Я уже начал расстраиваться, но зря. Ключевая позиция была на месте, не обманул.

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

Сидели с кайфом, пили чай, общались с людьми из интернета. И тут зашёл чайный чувак! Мы минут 30 обсуждали, как мне поставка, как этот блинчик, пробовал ли он такой с дикорастущих (это вообще космос был в моей жизни), где я брал такие раньше, что он рекомендует заценить ещё и просто о чае и жизни. Невероятно душевно.

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