Джависты здесь?

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

Чтобы было понятнее, скорее всего будут методы типа

void validateString(String str, int minLength, int maxLength)

И всевозможные комбинации.

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

Есть, к примеру, следующая запись:

public record Employee(String firstName, String lastName) {}

Чего здесь не хватает? Правильно, проверок на null для firstName и lastName. Ну так давайте добавим:

public record Employee(String firstName, String lastName) {
    public Employee {
        if (firstName == null) {
            throw new NullPointerException("firstName must not be null");
        }
        if (lastName == null) {
            throw new NullPointerException("lastName must not be null");
        }
    }
}

Как-то слишком длинно. Если у нас в проекте сотни подобных проверок (все ж пишут проверки, так ведь?🙂), то код сильно раздувается. Хочется покомпактнее. Вспоминаем, что в Java 8 появился метод Objects.requireNonNull(). Заменяем:

public Employee {
    Objects.requireNonNull(firstName, "firstName must not be null");
    Objects.requireNonNull(lastName, "lastName must not be null");
}

Гораздо лучше. Но теперь вспоминаем, что firstName и lastName также не могут быть пустыми. Objects.requireNonNull() тут уже не поможет. Придётся опять писать трёхстрочные if’ы? Не хочется. Можно создать какой-нибудь утилитный метод типа checkCondition(). Но наверняка в какой-нибудь библиотеке такое уже есть? Я в течение своей многолетней практики сталкивался с разными вариантами и в конце концов понял, что всё-таки лучшим образом эту проблему решили в Guava. В классе Preconditions:

public Employee {
    ...
    Preconditions.checkArgument(!firstName.isEmpty(), "firstName must not be empty");
    Preconditions.checkArgument(!lastName.isEmpty(), "lastName must not be empty");
}

Есть там и другие проверки: checkNotNull(), checkElementIndex(), checkPositionIndex(), checkState(). При этом checkArgument() из них самый универсальный, и с его помощью можно проверить любое boolean выражение:

Preconditions.checkArgument(firstName != null && !firstName.isEmpty(), "firstName must not be null or empty");
Preconditions.checkArgument(lastName != null && !lastName.isEmpty(), "lastName must not be null or empty");

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

В Гуаве при этом решено ещё несколько проблем.

Представим, что нам ещё надо добавить проверку на максимальную длину строки. Мы пишем в обычном if-стиле и случайно допускаем ошибку в шаблоне:

if (firstName.length() > MAX_LENGTH) {
    throw new IllegalArgumentException(String.format("firstName is too long, max length is %s, got %s", MAX_LENGTH));
}

Если в рантайме firstName оказался слишком длинным, то выбросится исключение, но совсем не IllegalArgumentException с красивым сообщением, а что-то совсем другое (MissingFormatArgumentException). Обидно. Гуава в этом плане более снисходительна. Вариант с Preconditions будет в любом случае бросать llegalArgumentException:

Preconditions.checkArgument(firstName.length() <= MAX_LENGTH, "firstName is too long, max length is %s, got %s", MAX_LENGTH);

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

Другая фишка – это стремление Гуавы не генерировать мусора. Все помнят, что в Java есть боксинг, а это значит, что простая сигнатура checkArgument() с Object… создавала бы обёртки над примитивными значениями каждый раз. Мелочь, но всё равно не очень приятно. Но в Гуаве у checkArgument() есть множество перегрузок для большинства простых случаев.

Например, в этом случае мусора не будет вообще, так как есть перегрузка checkArgument(boolean, String, int, int):

Preconditions.checkArgument(firstName.length() <= MAX_LENGTH, "firstName is too long, max length is %s, got %s", MAX_LENGTH, firstName.length());

Таким образом, Preconditions в Гуаве – это:
1. Компактно
2. Безопасно
3. Эффективно

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

#guava

Я тут полез в своих российских брокеров и обнаружил, что у меня пропал доступ к опционам. А раньше был 🤔.
В общем, статус квала получить я не могу, там нужны какие-то сложные бумажки теперь, мне такие слишком трудно делать.
Решил сдать тест в БКС, чтобы там доступ к опционами получить. Не сдал 😁

Посмотрел тут "Служебный роман". Раньше не смотрел. Мне очень понравилось. А ещё там есть несколько интересных моментов про работу в организации.

Директорша, как её называют в фильме.
Вообще говоря, совершенно неудивительно, что её никто из сотрудников не любит.

1. Обратная связь
- даёт корректирующую (да тут скорее даже негативную) ОС в присутствии третьего лица (своего нового зама, друга подчинённого)
- даёт личностную оценку сотруднику, вместо того, чтобы критиковать результат работы ("проблемы из-за таких ротозеев, как вы")
- не уточняет изначально мнение сотрудника, т.е. не допускает, что может быть не права сама ("вы используете непроверенные данные" вместо "вы проверяли данные?")
- не удостоверяется, что сотрудник согласен с такой оценкой, что он понял ошибку, как он её понял (даже не дожидается, пока он покинет кабинет, сразу переходит к диалогу с другим человеком)
TL;DR ОС от неё выглядит так: "Вы используете непроверенные данные. Из-за таких ротозеев, как вы, просрали страну. Идите переделывать. Что? Вопросы какие-то? Свободны"
С точки зрения сотрудника получается, что директор — это человек, который может по своему усмотрению тебя унизить, наказать и даже не дать шанса на оправдание.

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

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

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

Рядовой клерк, ванаби начальником отдела.

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

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

3. Боится задавать вопросы начальству. Боится проявлять инициативу. Боится даже когда кто-то идёт поговорить с директоршей за него.
Здесь, кажется, играют два фактора. Первое — начальница-тиран. А вот второе — это то, что сотрудник, видимо, сам понимает, что заслуг у него никаких нет. Не за что должность давать. Но признаться сам себе в том не может. Видно, что человек себя высоко ценит, но напускает ложную скромность, чтобы получить побольше подтверждения своей хорошести от друзей-коллег.

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

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

2. В своих попытках произвести впечатление он теряет границы дозволенного. Зачем-то отвешивает совершенно нелепый и грубый "комплимент" секретарше. Чем только отталкивает её. Видимо, уверил сам себя, что он мачо, и все его хотят.

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

Но вот как корректно справится с такой ситуацией? Пишите ваши варианты в комментарии.

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

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

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

Зато поделюсь впечатлениями от программирования. Я перед новым годом брал отпуск и пару дней потратил на то, чтобы написать бота, который будет учитывать наши расходы (дожили до той стадии, когда уже надо).
Писал на питоне, использовал 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

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

ЕТО СТАРАСТЬ

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