Если серьёзно, если взаимодействовать с коллегами с утра до вечера, то узнаете их намного лучше. Поскольку программирование — это работа, а не клуб по интересам...

… то внезапно может оказаться, что ваши коллеги — это люди с кучей несовместимых с вами тараканов в голове. Иными словами, совершенно не те люди, с которыми вы хотите непрерывно проводить 8+ часов 5 дней в неделю.

Я больше времени программирую, потому что меньше туплю

Конкретно водитель больше программирует, но сомневаюсь, что больше, чем три человека.

Нет такого понятия, как «мой кусочек» кода

Для избавления от этой проблемы обязательные code-review куда эффективнее.

Да. Собственно, rps и расшифровывается как «requests per second».

Disclaimer: я не питонист, так что не уверен, что нагуглил правильно.

Использовать пакет ratelimit выглядит подходящим решением.

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

Кстати говоря, увидев заголовок статьи, изначально ожидал встретить в статье описание обхода 429 Too Many Requests.

Из-за незнания постоянно пользовался onComplete или onSuccess методами из akka-http.

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

Не знаю упоминалось ли в статье, но еще одна важная, на мой взгляд тема связанная с actor-ами и future: doc.akka.io/docs/akka/current/general/jmm.html#actors-and-shared-mutable-state

В статье явно эта тема не затрагивалась, но именно по этой причине в акторе HttpBookingClient.ClientActor обратное изменение функции поведения на default инициируется отправкой сообщения себе:

p.future.onComplete(_ => self ! Completed)

В общем и целом согласен. Если честно, мне даже хотелось начать заголовок статьи со слова «анти-паттерн», но не стал лепить такой ярлык.

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

Актор может быть нужен для хранения изменяющегося состояния и выполнения действий в зависимости от него. В примере с букингом из статьи это состояние — выполняется сейчас HTTP-запрос или нет. В то же время клиенты как раз и знают только про обычный сервисный класс BookingClient с понятным интерфейсом.