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

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

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

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

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

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

ЕТО СТАРАСТЬ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Про размер задач

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

Аргументы "за" такие:
- маленькие задачи чаще завершаются (потому что их быстрее делать) — каждая закрытая задача это дофаминчик; с большими задачами ребята начинают грустить и выгорать (все вон сколько задач закрыли, а я одну еле успел!)
- с маленькими (=короткими) задачами сильно ниже вероятность того, что кто-то делал, делал, а потом заболел, и задача висит, ждёт его; никто не хочет заново разбираться в большой задаче, тратить кучу времени, чтобы доделать оставшиеся 10%
- с маленькими задачами лучше предсказуемость времени выполнения (об этом фотка)
- маленькие задачи проще раскидать на толпу разрабов, если вдруг загорелись сроки
- маленькие задачи => маленькие ПРы (тут сами знаете)

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

Друзья мои!
Мне таки удалось найти и восстановить офигительные материалы по
1. Истории и архитектуре ЭВМ от Митропольского, одного из создателей БЭСМ-6 и моего зав. кафа (предыдущий пост)
2. Истории и философии науки, с курса аспирантуры МФТИ (предыдущий пост)

Я настолько рад, что меня распирает! Стащите себе, пожалуйста, это должно жить.

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

Жена пекла круглые пончики, а получились квадратные. Говорит, что они такие, какие и должны быть, просто в мере L1 получились.

Дочитал книгу Дорофеева "Джедайские техники"

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

Потом у меня была (и продолжается) стадия отрицания. Весь этот дроч про личную эффективность мне отвратителен. Двадцатилетние люди рассказывают, как они здорово питаются, здорово спят, здорово занимаются спортом, каждый день медитируют по часу, изучают новые области, технологии и тренды, ведут блоги, путешествуют. И ПРИ ЭТОМ замечательно себя чувствуют, хорошо высыпаются, никогда не готовят сами, работают 90 часов в неделю, встречаются с друзьями попить пива пару раз в неделю. НУЖНО ВСЕГО ЛИШЬ поверить в себя, родиться крутым, регулярно ходить к психотерапевту (вы тоже часто опускаете приставку психо, потому что звучит так себе? Я да) и врать.
Биохакинг и фотография Сержа Фаге здесь.

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

ТАК ВОТ. Я не хотел читать книжку по личной эффективности. Потому что я в неё не верю.
Но есть две вещи:
1. Прежде чем критиковать, прочитай
2. У меня реально стали возникать вопросы, как планировать день, когда у тебя тонна работы и миллиард встреч в день

Книжка топ!
Там на самом деле ничего нет про "просто ходи в зал три раза в неделю и сможешь работать 70 часов". Потому что это всё файн тюнинг.
Книжка просто помогает тебе правильно использовать уже имеющийся ресурс. Планировать день. Ничего не забывать. Использовать огрызки времени (если очень уж хочется).
Это прям то, что мне было нужно _сейчас_. До этого, я прекрасно справлялся и без всяких техник, они мне были не нужны, а потому и казались бесполезными.

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

Спасибо, Максим 🤝

Почему сербы больше любят кириллицу?

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

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

В русской орфографии произношение согласного зависит от следующего за ним знака. Например, серый (мягкая с), но сэры (твёрдая с). Или сядь (мягкая д), но сад (твёрдая д).
В сербской орфографии такой зависимости нет. Для мягких согласных есть специальные символы. Например, пријатељ (друг, мягкая л), но пола (половина, твёрдая л). Как видите, символ ј используется вместо русской й.
А вот в сербской латинице у знака ј появляется второй смысл, мягкого знака. Будет уже prijatelj. Один и тот же знак, в одном слове, в разных позициях имеет разную семантику, уже тут вы могли при чтении споткнуться глазами. Но посмотрите, например, на on je lenjiji (он ленивее, кириллицей было бы он је лењији).

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

Не знаю, как вы, а я ждал и дождался. У одного из самых активных комментаторов этого канала появился свой блог. Если соскучились по постам о торговле на биржах и программировании, то бегите срочно смотреть
https://t.iss.one/engineer10x

Прочитал The Culture Code Дэниэла Койла

Эта книга вообще не про IT и не про руководство, но про построение команды (в противовес набору исполнителей). Как из просто групп людей могут образоваться настоящие команды.

Книга разбита на три части: построение доверия, разделение с командой уязвимости и установление предназначения. Это хорошо перекликается с известными (мне) по другим источникам характеристикам команды: safety, interdependence, cooperation. Про них в книге тоже много говорится.

Если коротко, то
1. у команды есть направление, цель, которую все члены команды понимают и разделяют, т.е. все движутся в одном направлении
2. все в команде чувствуют себя в безопасности, знают, что можно ошибаться, знают, что другие не осудят, т.е. они могут положиться на товарищей и не думать о прикрытии тыла, оттуда не прилетит
3. всё это в совокупности порождает кооперацию, т.е. люди доверяют друг другу и знают, что у них общие цели, а значит можно и нужно просить помощи и помогать

Автор начинает свой путь с посещения учёных из австралийского университета, которые исследуют поведение людей в группах. А дальше он ходит по разным командам из совершенно разных коллективов: от гугл и zappos до воров и баскетбольных команд, и наблюдает за ними. Таким образом в книге появилось очень много наблюдений, ярких картинок, которые помогают запоминать основные идеи. Автор утверждает, что посетил 40 успешных и около 400 неуспешных групп, не вижу смысла ему не доверять 🙂

Всего в книге три части, в конце каждой есть глава с набором идей для внедрения в жизнь. Это супер формат. Мне очень удобно было возвращаться и перечитывать.

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

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

Смотрите, моя подруга Таня делает конференцию про применение AI в реальной работе. Это, конечно, не как мы тут любим, про кишки подобных систем, но вот лично я, например, пока не научился нифига подчинять себе *GPT, а надо бы.
Там в конце поста промик на скидку для своих*

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

Идея довольно простая. Так как мы не знаем, до каких точно уровней поднимется цена, а только точно знаем, что не выше, чем Х, то не очень понятно, какую цену в лимитник зашивать.
А про то, до каких уровней может падать цена, мы вообще ничего не знаем, кроме исторических наблюдений и каких-то своих моделей/вью/веры в чудо.

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

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

Легко видеть, что эта стратегия требует капиталовложений (и некоторой толерантности к риску). Не только лишь все могут себе такое позволить.

И честно говоря, не видно, чтобы кто-то реально это делал в серьёзных объёмах. Можете ради интереса посмотреть на EURCHF в период peg'а, там курс был плотненько прижат к потолку этими вашими трейдерами (они там, к слову, обосрались, ЦБ Швейцарии победил).

*не является инвестиционной рекомендацией

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