Телеграм канал «Coder Doesn’t Know»

Привет! 👋

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

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

Помимо подготовки к интервью, будут и другие активности - оставлю немного интриги 👋

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

Участие полностью бесплатное. ✨

Если тебе близка эта идея, заполни Google Form 🫲 и я скоро вернусь к тебе. ❤️

Сколько потоков нужно вашему сервису?

Java, Go, Python, C#, Node.js и другие языки требуют от разработчика понимания того, как правильно выбрать уровень конкурентности сервиса, чтобы он, во-первых, не простаивал 🏝, а во-вторых, не умирал под нагрузкой 👨‍💻.

Давай разберёмся, как ответить на этот вопрос - как на собеседовании, так и во время брейншторма с коллегами.

На первый взгляд, всё довольно просто. Есть два основных типа задач:

1️⃣ CPU-bound - задачи, в которых основное время уходит на вычисления процессором. Например, сортировка больших массивов или обработка данных.

Для начала смотрим на количество доступных ядер процессора (они же CPU cores). Если у нас 8️⃣ ядер, то для CPU-bound задач разумная отправная точка - около 8️⃣ потоков, одновременно выполняющих вычисления.

Почему, к примеру, не 80? Потому что процессор всё равно не сможет одновременно выполнять 80 вычислительных задач на 8️⃣ ядрах. Лишние потоки могут добавить накладные расходы на переключение контекста. Это не значит, что 8️⃣ потоков всегда дадут оптимальный результат: всё зависит от нагрузки, ограничений CPU и особенностей приложения. Но можно начать с этого значения.

2️⃣I/O-bound - задачи, в которых основное время уходит на ожидание ответа от базы данных, сети или файловой системы.

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

Для предварительной оценки есть простая формула:

Threads ≈ CPU cores × (1 + Wait Time / CPU Time)


Допустим, у нас сервис с, нами любимыми, 8️⃣ ядрами процессора. Один запрос тратит 10 миллисекунд на обработку бизнес-логики, а потом ещё 90 миллисекунд ждёт ответа от базы данных. Получается, что всего запрос занимает 100 миллисекунд, но CPU мы используем только 10 миллисекунд. Остальные 90 миллисекунд наш поток просто ждёт. Подставив значения в формулу выше, получим:

8 ядер × (1 + 90 миллисекунд простоя / 10 миллисекунд обработки) = 80 потоков


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

Что, если у нас может быть всего одно соединение к БД?

Даже если мы создадим 80 потоков, одновременно использовать соединение сможет только один запрос. Остальные будут ждать, пока оно освободится.
Если запрос занимает 100 миллисекунд и удерживает соединение всё это время, то теоретическая пропускная способность составит:

1 соединение / 0,1 секунды = 10 запросов в секунду

А если у нас 20 соединений?

То при тех же условиях теоретический предел уже около 200 запросов в секунду:

20 соединений / 0,1 секунды = 200 запросов в секунду

Конечно, есть много НО. Например, сможет ли сама база данных обрабатывать такую нагрузку без роста задержек? А что, если запросы начнут выполняться дольше? И не станет ли другое место в системе узким горлышком?

Тут главное не начать путать количество потоков в приложении и количество соединений с базой. Это не одно и то же.

Нет точной формулы, что выдаст точно правильное количество потоков, которые нужно сервису потому что есть сотня "но". Однако то, что я описал выше - отправная точка. После неё нужно смотреть на реальные метрики: CPU utilization, throughput, p95/p99 latency, длину очередей и время ожидания соединений.

TL;DR или что нужно сказать, если лень углубляться?

1️⃣CPU-bound: начать с количества доступных ядер процессора и проверить результат нагрузочным тестированием.
2️⃣I/O-bound: оценить соотношение времени ожидания и времени вычислений. Для начальной оценки можно использовать формулу:

Threads ≈ CPU cores × (1 + Wait Time / CPU Time)


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

Всё 😊.

По вечерам я пишу код с LLM, можно переименовать канал в Clauder Doesn't Know 😆

Изначально у меня была идея взять подписку за $20 и с небольшой помощью Codex/Claude написать какой-нибудь пет-проект. Через несколько дней у меня закончились токены 😂. Взял подписку подороже. После и её стало хватать впритык ✨. А ещё интересно, как быстро начинаешь лениться. Если сначала долго с ним общаешься, скрупулёзно проверяешь design docs, а потом проверяешь практически каждое предложенное изменение, то уже через неделю начинаешь гораздо более поверхностно смотреть на то, что он делает. Кстати, решения, которые предлагал Codex, довольно часто оказывались сложнее, чем нужно, избыточными, а иногда просто странными.

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

После этого извращения возникает несколько вопросов:

1️⃣, разве с LLM вообще можно остановиться придумывать новые фичи? Если реализация очередной идеи стоит практически ничего, почему бы не добавить ещё одну? Тут главное, чтобы не получилось очередное "super intelligence app" 😂.

2️⃣, разве вообще возможно нормально заревьюить 1️⃣0️⃣0️⃣0️⃣0️⃣0️⃣ строк кода, которые агент тебе периодически предлагает несмотря на то, что ты просишь делать лаконичные и небольшие пулл реквесты?

И 3️⃣, а надо ли это? Если нагрузки в проекте нет и им будет пользоваться, в лучшем случае, 10–100 человек, то ревью вполне может быть поверхностным, а то и вовсе отсутствовать.

И получается довольно забавная ситуация: раньше я думал, что LLM позволит мне быстрее писать код, а теперь основная проблема уже не в том, как быстро я могу сделать очередную фичу, а в том, сколько кода я потом готов самостоятельно понять и проверить.

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

Performance review, она же оценка эффективности сотрудника, в компании типа Google

Немного контекста вначале:

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

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

Во время performance review ты получаешь оценку своей работы по определенной системе:

1️⃣Ниже ожиданий
2️⃣Оправдал ожидания
3️⃣Превзошел ожидания

Performance review также может влиять на твою компенсацию: базовую зарплату, годовой бонус и акции. Повышение зарплаты каждый год, конечно же, в контракте не прописано, но все надеются на лучшее 😂.

Немного про акции:

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

Получается что-то вроде скользящего окна: сначала у тебя есть акции на четыре года вперед → проходит год → часть акций становится твоей → тебе могут выдать новый пакет → и снова появляется новая порция акций.

Важно понимать, что это не гарантировано. Размер нового пакета зависит от компании, твоего performance, уровня и, возможно, силы земли 🥒.

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

Вернемся к самому ревью:

Допустим, ты Senior Software Engineer 😨.

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

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

Когда подходит формальный review:

1️⃣Ты заполняешь self-review, он же самоотчет эффективности.

Здесь ты подробно расписываешь, что сделал(а), над чем работаешь и что стоит исправить или улучшить.

2️⃣Дальше в игру вступает peer feedback, он же оценка тебя коллегами.

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

3️⃣После этого менеджер формирует свою оценку.

Она основывается не только на self-review и peer feedback, но и на собственных наблюдениях менеджера за твоей работой в течение года. В теории self-review, отзывы от коллег и оценка менеджера должны складываться в одну объемную картину, которая не противоречит сама себе. После этого может проходить отдельный этап - calibration. Менеджеры и руководители обсуждают оценки сотрудников, чтобы привести их к более единому стандарту и сопоставить результаты людей одного уровня.

После ревью:

В итоге ты получаешь рейтинг, который может повлиять на деньги, которые ты получишь.
А дальше цикл повторяется: новые проекты → новый feedback → новый self-review → новая оценка → новая компенсация.

То есть performance review - это формализованный процесс, который связывает между собой твою производительность, твой карьерный прогресс и твою компенсацию.

Также, ходят мнения, что performance review сделан, чтобы ты не ходил(а) каждые три месяца к менеджеру за повышением зарплаты 🤣.