fa
Feedback

فریب کلاهبرداران را نخورید! تل‌متریو این کانال‌ها را شناسایی و برچسب‌گذاری می‌کند 👉 برای مشاهده برچسب، اشتراک تهیه کنید

this->notes.

this->notes.

رفتن به کانال در Telegram

О разработке, архитектуре и C++. Tags: #common, #cpp, #highload и другие можно найти поиском. Задачки: #poll. Мои публикации: #pub. Автор и предложка: @vanyakhodor. GitHub: dasfex.

نمایش بیشتر
4 491
مشترکین
-224 ساعت
-57 روز
-2230 روز
جذب مشترکین
اکتبر '26
اکتبر '26
+28
در 0 کانال‌ها
سپتامبر '26
+51
در 0 کانال‌ها
Get PRO
اوت '26
+53
در 2 کانال‌ها
Get PRO
ژوئیه '26
+37
در 1 کانال‌ها
Get PRO
ژوئن '26
+53
در 2 کانال‌ها
Get PRO
مه '26
+106
در 0 کانال‌ها
Get PRO
آوریل '26
+70
در 1 کانال‌ها
Get PRO
مارس '26
+57
در 2 کانال‌ها
Get PRO
فوریه '26
+30
در 0 کانال‌ها
Get PRO
ژانویه '26
+69
در 0 کانال‌ها
Get PRO
دسامبر '25
+75
در 0 کانال‌ها
Get PRO
نوامبر '25
+75
در 1 کانال‌ها
Get PRO
اکتبر '25
+141
در 3 کانال‌ها
Get PRO
سپتامبر '25
+1 111
در 1 کانال‌ها
Get PRO
اوت '25
+774
در 1 کانال‌ها
Get PRO
ژوئیه '25
+342
در 3 کانال‌ها
Get PRO
ژوئن '25
+94
در 2 کانال‌ها
Get PRO
مه '25
+100
در 2 کانال‌ها
Get PRO
آوریل '25
+71
در 1 کانال‌ها
Get PRO
مارس '25
+63
در 2 کانال‌ها
Get PRO
فوریه '25
+51
در 1 کانال‌ها
Get PRO
ژانویه '25
+34
در 0 کانال‌ها
Get PRO
دسامبر '24
+56
در 0 کانال‌ها
Get PRO
نوامبر '24
+100
در 1 کانال‌ها
Get PRO
اکتبر '24
+93
در 1 کانال‌ها
Get PRO
سپتامبر '24
+220
در 2 کانال‌ها
Get PRO
اوت '24
+76
در 0 کانال‌ها
Get PRO
ژوئیه '24
+155
در 1 کانال‌ها
Get PRO
ژوئن '24
+44
در 1 کانال‌ها
Get PRO
مه '24
+86
در 0 کانال‌ها
Get PRO
آوریل '24
+144
در 5 کانال‌ها
Get PRO
مارس '24
+100
در 1 کانال‌ها
Get PRO
فوریه '24
+64
در 0 کانال‌ها
Get PRO
ژانویه '24
+132
در 0 کانال‌ها
Get PRO
دسامبر '23
+26
در 0 کانال‌ها
Get PRO
نوامبر '23
+16
در 0 کانال‌ها
Get PRO
اکتبر '23
+26
در 0 کانال‌ها
Get PRO
سپتامبر '23
+29
در 0 کانال‌ها
Get PRO
اوت '23
+29
در 0 کانال‌ها
Get PRO
ژوئیه '23
+63
در 0 کانال‌ها
Get PRO
ژوئن '23
+50
در 0 کانال‌ها
Get PRO
مه '23
+53
در 0 کانال‌ها
Get PRO
آوریل '23
+145
در 0 کانال‌ها
Get PRO
مارس '23
+48
در 0 کانال‌ها
Get PRO
فوریه '23
+46
در 0 کانال‌ها
Get PRO
ژانویه '23
+38
در 0 کانال‌ها
Get PRO
دسامبر '22
+33
در 0 کانال‌ها
Get PRO
نوامبر '22
+60
در 0 کانال‌ها
Get PRO
اکتبر '22
+37
در 0 کانال‌ها
Get PRO
سپتامبر '22
+90
در 0 کانال‌ها
Get PRO
اوت '22
+49
در 0 کانال‌ها
Get PRO
ژوئیه '22
+352
در 0 کانال‌ها
تاریخ
رشد مشترکین
اشارات
کانال‌ها
26 اکتبر+2
25 اکتبر0
24 اکتبر+4
23 اکتبر+1
22 اکتبر+2
21 اکتبر+3
20 اکتبر+1
19 اکتبر+1
18 اکتبر+2
17 اکتبر0
16 اکتبر+1
15 اکتبر+1
14 اکتبر+1
13 اکتبر+1
12 اکتبر0
11 اکتبر+3
10 اکتبر+1
09 اکتبر0
08 اکتبر+2
07 اکتبر+1
06 اکتبر0
05 اکتبر0
04 اکتبر0
03 اکتبر+1
02 اکتبر0
01 اکتبر0
پست‌های کانال
#cpp Хочу попробовать уточнить вашу модель понимания комитета развития стандарта C++ (в сторону моей картинки, конечно же). Я время от времени слышу/вижу фразу вида «ооо, опять сделали бесполезную фичу X. Могли бы на что-то другое время потратить. Например на А, Б или В.». Комитет — это буквально сборище заинтересованных. Да, некоторые члены представляют компании и получают за это деньги. Некоторые — современные глыбы, которые уже исторически стоят за языком и активно занимаются основными проблемами (в данном случае безопасность у условных Bjarne/Herb). Большинство — энтузиасты. Они хотят сделать язык лучше. У них есть некоторое представление того, как должен выглядеть Х в языке. Возможно они пришли в комитет, потому что им только этот Х и интересен. Или часть языка вокруг Х. Ну или может просто что-то делать им хочется, а Х под руку попался. Когда вы видите новую фичу X и думаете «лучше бы они сделали Y», полезно помнить: скорее всего, не существовало момента, когда комитет сел за стол и решил потратить ресурсы на X вместо Y. Возможно, просто нашёлся человек, который был готов пять лет заниматься X, а человека, готового пять лет заниматься Y, не нашлось. Что было бы, если бы Х никто не занимался? Возможно, стандарт был бы точно таким же, но без фичи Х. Может освободившийся ресурс различных групп на обсуждение, ревью и бюрократию позволил бы взглянуть и протащить дальше по процессу Y (какова вероятность, что Y вам тоже нужен?). Или может освободившийся ресурс мог бы сделать уже добавленный в стандарт Y ещё чуть лучше. Связь очень неявная. Комитет это вообще не единая сущность, как мы привыкли думать. Это сложная децентрализованная (в большей мере) бюрократическая машина, в которую можно попытаться законтрибьютить. Специфический опенсорс, можно сказать. Конец не сформулировал. Но вы поняли. @thisnotes. Patreon, newsletter. Спасибо Artyom Garkavy и niki4smirn.

2
#cpp Недавно у меня спросили, чем может быть полезно иметь константную rvalue-ссылку (const Type&&). Моя первая мгновенная реакция — ничем. Я такого никогда не писал. Я никогда не видел, чтобы кто-то рядом так писал. Я никогда не видел, чтобы про это говорили как про «редкую возможность C++, которая нужна в тех трёх случаях». Опыт кричит, что это глупость какая-то. Но это же C++. Давайте подумаем семантику такого типа. Это фактически временный объект, который по какой-то невообразимой причине должен быть константным. Что с таким объектом делать дальше, непонятно. Но может с ним и не нужно ничего делать? Представьте код, в котором вы принимаете ссылку на какой-то объект и сохраняете его адрес: Obj* ptr; void UpdatePtr(const Obj& o) { ptr = &o; } Проблема в том, что можно написать: UpdatePtr(Obj{}); И мы получим dangling pointer. const lvalue-reference разрешает слишком много. Нам нужно удостовериться, что мы принимаем настоящий lvalue-объект. Можно запретить const rvalue-reference перегрузку: void UpdatePtr(const Obj&&) = delete; Получим такое: Obj o; UpdatePtr(o); // NICE const Obj co; UpdatePtr(co); // NICE UpdatePtr(Obj{}); // ERROR const Obj MakeObj(); UpdatePtr(MakeObj()); // ERROR Обычная специализация для Obj&& такую проблему не решит, так как тут нам нужно избавиться от константности Obj. И это реально нужно (если вы пишите какую-нибудь мегасуперпупер дженерик либу)! Взгляните на кусочек cref: template< class T > void cref( const T&& ) = delete; Потому что вы не хотите уметь делать std::cref(T{}). Ещё одна фича запрета такой перегрузки: явная ошибка компиляции юзеру, который пытается мувнуть константный объект. «Ну зачем тебе его мувать, если это копия? Может ты что-то не то делаешь?». Типа вот так намекнуть. Другой пример, пусть и мутноватый, можно найти в перегрузках метода value() в std::optional: constexpr T& value() &; constexpr const T& value() const &; constexpr T&& value() &&; constexpr const T&& value() const &&; Первые три понятно. Зачем нужен последний? Представьте, что у юзера какой-то такой код: void f(const Obj& o); void f(const Obj&& o); const std::optional<Obj> opt = Get(); f(std::move(opt).value()); Тут жизненно необходимо сохранить информацию и про const, и про rvalue-reference, потому что это радикально влияет на overload resolution. Вы спросите, а зачем юзер написал такой код? Да я сам хз. Это не моё дело. И не дело разработчиков стандартной библиотеки. Их дело — сохранить всю доступную информацию для общего случая. Как ей распоряжаются, без понятия. @thisnotes. Patreon, newsletter. Спасибо Artyom Garkavy и niki4smirn.
1 608
3
#highload Sharding 101. Давайте быстро пробежимся и зафиксируем концепции, которые важно помнить при шардировании. Хотелось бы, чтобы этот пост был заметкой с ключевыми словами, которые вы поклодите при необходимости. Задача шардирования: разбить данные на куски, если одна машинка не справляется держать всё (потому что данных слишком много или нагрузка очень большая). Чтобы шардировать, надо выбрать ключ: по нему вы будете сначала раскладывать данные по шардам, а потом понимать, где данные искать. Ключ нужен нормальный. timestamp — плохой ключ: шард для новых данных всегда мега горячий. Шардировать можно: • по значениям ключей. Очень просто: берёте все значения (или их префиксы, например по первому символу в uuid) и для последовательных ренджей выделяете по шарду ([a-c] -> shard 1, [d-g] -> shard 2, ...). Проблема в том, что нужно выбрать такие ренджи, чтобы шарды были примерно одинаковыми. Если паттерн наличия данных/нагрузки приводит к hot шардам, проблема. Шарды всегда можно сплитить на побольше и поменьше. Можно автоматически. По ключам хорошо, если вам важно иметь рядом данные, ключи которых тоже рядом. Но это не всегда так. Можно • по хешам от ключей. Посчитали хеш и взяли остаток от деления на кол-во шардов. Правда решардинг (+/-1 шард) приводит к полному решардингу данных. Можно делать много виртуальных шардов для маленького кол-ва реальных хостов (Count(virtual) — большое составное число, произведение большого кол-ва первых простых числе в идеале, так проще). Лучше разбивать хеши на ренджи. Отсюда растёт consistent hashing: организовываете всё пространство хешей в логическое кольцо, расставляете на нём шарды. Найти ближайший шард для ключа == взять следующий по часовой стрелке. Так вы сокращаете кол-во перераспределений данных при появлении/пропаже шардов. Тут есть разные варианты реализации (rendezvous hashing, jump consistent hashing, etc). Это всё было stateless sharding. Но иногда вам нужна чуть более сложная логика. И хранить информацию о том, что где хранится, нужно в отдельной БД. Пару примеров, когда это оправдано: • динамический шардинг. Вы пишете систему, которая по каким-то вам известным правилам умеет делить/мержить шарды. • может у вас мессенджер. Хранить чаты можно частями по блокам (для очень больших чатов это м.б. выгодно). Новые блоки можно начинать писать на новые шарды, когда на старых места уже нет. • гео-шардинг. Причём со сложной конфигурацией для большого кол-ва регионов и клиентов в них. В общем случае всегда, когда у вас есть какая-то метадата. Про вот этот второй вариант stateful шардирования с какой-то application логикой часто забывают на system design собеседованиях. Потому что про них редко говорят в туториалах и разборах. А зря. Там есть много полезных и красивых вариантов. Важно только не забыть, что сервис с метаданными, — доп точка отказа. А может вы вообще можете забить на это всё, ведь паттерны работы с данными простые. Возьмите тогда Amazon DynamoDB, которая умеет шардироваться автоматически (и по объёму, и по нагрузке) и не думайте про это. Только посчитайте, сколько это будет стоить. @thisnotes. Patreon, newsletter. Спасибо Artyom Garkavy и niki4smirn.
1 399
4
/91
1
5
#common На хабре есть отдельный вид постов: перевод. Значит осуждаю переводы по нескольким причинам: • перевод не добавляет ценности. Статья уже написана. • в переводе так или иначе теряется стиль автора. При неумелом переводе ещё и смысл искажается. • человек, переводивший контент, получает плюсики. Лайкают же не факт перевода, а контент. А мог бы изначальный автор получить доп просмотры у себя на сайтике. • в век засилия ллм ещё неизвестно, кто и как там переводил. Возможно постящий/-ая (я не хочу использовать слово автор) исполнил роль копирующего туда-сюда устройства. • перевод существует для тех, у кого проблемы с иностранным языком. Я уверен, что 99.99% переводов делаются с английского. Если вы читаете статью на русском, потому что вам сложен English (fabric, details), подучите язык. Вы же всё-таки программисты. Инженеры. Вам столько документации читать придётся. А вы статью не можете осилить. Если перевод с другого языка, имеет полное право быть. Никаких вопросов. На всякий случай, скрываться не буду. Моя первая статья на хабре (/91) тоже была переводом. В своё оправдание хочу сказать: • я изменился • это не был просто перевод. Это была расшифровка куска доклада на английском. Причём не вот эта расшифровка, как любят всякие крупные конференции поверх докладов статьи выкладывать. С «мм», «ну вот тут так сделаем», «видите на слайде вот это место?» (нет, не вижу, я читаю текст, а не смотрю видео). А внятная адаптация контента на конкретную тему. Я поверх потом ещё статью сам писал, так что там в каком-то смысле цепочка была так запущена. Я бывает кликну на статью на хабре. Название интересное. Вижу, что перевод. Через секунду уже читаю оригинал. Иногда до абсурдного доходит: https://habr.com/ru/articles/841698/ @thisnotes. Patreon, newsletter. Спасибо Artyom Garkavy и niki4smirn.
1 916
6
#highload Давайте представим, что у вас есть пару датацентров и по какой-то причине вы потеряли некоторые. Чуть ли не все. Что делать? Конечно, не дай бог кому-то попасть в такой кризис. Но план выживания примерно такой: • определить критический функционал и операции, которые необходимо поддержать любой ценой. Сфокусироваться на этой части ваших сервисов. Остальные выключить для максимальной экономии ресурсов. В идеале, вы должны знать критическую цепь в любой момент жизни продукта. • увести нагрузку (если есть что уводить) на работающее и доступное железо • активно позабирать ресурсы там, где они используются неэффективно, и отдать туда, где их критически не хватает (в идеале это всегда должно выполняться, но достичь этого сложно). Восстанавливать сервисы надо по приоритетам, а не наобум. В такой ситуации (как и во многих других) жизненно необходимо уметь правильно функционально деградировать. Вспомним пост от начала года: https://t.me/thisnotes/399 Год назад примерно в окрестности этого времени я активно исследовал, что нужно сделать, чтобы иметь инструмент вида «по кнопке отключить всё кроме самого важного». К сожалению, бизнес устроен так, что такими долгосрочными вещами заниматься почти наверняка нельзя. Это всегда nice to have. До тех пор, пока попа не отвалится (конечно, и я мог бы лучше продавать проекты, но как есть). Прийти к чему-то материальному и полезному не получилось. Ну что ж. @thisnotes. Patreon (сюда можно донатить, чтобы мои дц жили вечно), newsletter. Спасибо Artyom Garkavy и niki4smirn.
2 509
7
#perf Осознанно не пишу ничего про ИИ, но не удержался. Есть такой хорошо известный в среднего размера (а может даже и в широких) кругах чувак — Антон Самохвалов. Я несколько раз его периодами читал, но так как мои интересы не очень матчились с его контентом, я переставал. Недавно узнал про концепцию, которой я очень хочу с вами поделиться. Про неё ниже. В целом сейчас, я кажется, в каком-то смысле до контента Антона «дорос», так что в этот раз планирую на канале задержаться. Про концепцию поверх постов Антона мне рассказал близкий друг. А я во время полёта домой casually перечитал канал Антона с начала лета, вдохновился ещё больше и заодно нашёл несколько примеров, чтобы вам было понятнее. Поинт такой: раз сегодня с засилием LLM код становится дешёвым, появляется смысл делать (или даже нет смысла НЕ делать) некоторые оптимизации (да и проекты в целом), за которые раньше ни за что бы никто не сел. Более того, generic решения уходят в прошлое, потому что имея систему, вы можете три доллара понять, что нужно ВАМ в конкретном случае и наклодить частное решение под ваш конкретный юзкейс. Перф даётся проще, если вы знаете, где его искать. Примеры: • посмотрел на конкретный паттерн использования памяти и написал аллокатор ровно под него: https://t.me/itpgchannel/4165 • perfect hash с доработками для фиксированного набора расширений файлов: https://t.me/itpgchannel/4184 • огромная стейт машина, которую наклоденерил за 7 часов: https://t.me/itpgchannel/4313 • научился писать данные максимально эффективно на своё конкретное железо в своём конкретном S3: https://t.me/itpgchannel/4484 • тут Антон и сам бы справился, но сэкономил себе нормально так ресурса: https://t.me/itpgchannel/4242 Тут общая концепция словами автора: https://t.me/itpgchannel/4344 и продолжение: https://t.me/itpgchannel/4379 Думаю, вы ощутили, что имелось в виду выше. Я в последнее время иногда занимаюсь большим проектиком (когда-нибудь вам покажу). И там постоянно натыкаюсь на шероховатости стандартной библиотеки (в которой я вижу general решения, пытающиеся угодить всем). Я постоянно возвращался к мысли, что для перфа частные решения, даже для таких общих вещей, неимоверно важны. А тут оно как-то сматчилось с идеей со стороны и нашло продолжение в связи с ИИ. Причём у меня после осознания подхода ещё и направление мысли сменилось. Я в целом вообще теперь не вижу смысла особо писать код руками, хотя ещё неделю назад был уверен, что навык это важный (ну он и всё ещё важный, так или иначе. Я бы опустил рандомного сеньора, который почему-то разучился этим заниматься. Но, кажется, на хорошем наборе примеров я понял всех важных дядек из всех больших компаний). Человек трудящийся уходит в прошлое. В дело вступает человек думающий. У разработчика без глубокой картины происходящего, с узким кругозором, и агент будет использоваться кустарно, чтобы подпереть да подкрутить. Если вы найдёте способы и силы развиваться качественно в текущих условиях, вы не то чтобы станете легитимными 10х, но и всеми 228х разработчиками. Качайтесь и читайте Антона: @itpgchannel. @thisnotes. Patreon, newsletter. Спасибо Artyom Garkavy и niki4smirn. Хотите advent about bad parts стандартной библиотеки в декабре? Если хотите, тыкайте 🌚. Если нет: 🗿.
2 529
8
#cpp В стандартной библиотеке иногда встречаются функции, которые не выглядят однозначно. Один из таких примеров: std::exchange: template< class T, class U = T > T exchange( T& obj, U&& new_value ); Что делает функция? Она присваивает obj new_value, и возвращает старое значение obj. Т.е. код ниже эквивалентен: auto var = std::exchange(a, b); auto var = a; a = b; (я конечно опустил детали move/forward, потому что сейчас важна концепция) Зачем эта функция нужна? Явно не для сокращения кода на строчку каждый раз, когда у вас возникает подобная ситуация. В стандартную библиотеку ради такого вряд ли бы добавили что-то. Скорее ради упрощения какой-то частой операции. Или для выражения какой-то конкретной семантики. Вот тут как раз второй случай. Примеры: • хотим сбросить флаг, при этом прочитав старое значение: if (std::exchange(shutdown_requested_, false)) { shutdown(); } • передача владения в move-кторе: Widget(Widget&& other) : handle_(std::exchange(other.handle_, nullptr)) {} • извлечение текущего состояние (с переходом в следующее): auto old_state = std::exchange(state_, State::Running); process(old_state); • получить значение optional и очистить его: auto value = std::exchange(pending_value_, std::nullopt); Плохие примеры: • присваивание: std::exchange(enabled_, true); enabled_ = true; • старое значение можно выразить очевиднее: auto old = std::exchange(counter_, counter_ + 1); auto old = counter_++; • когда содержит сложное вычисление: auto old = std::exchange( state_, compute_next_state(state_, request, dependencies)); Тут надо разбираться в порядке evaluation. Код может быть не таким очевидным. • использовать функцию ради одной строки: auto old_name = std::exchange(name_, new_name); Тут нет какого-то внятного изменения состояния. Просто пачка переприсваиваний. • swap: auto old = std::exchange(a, b); b = old; std::swap(a, b); Короче когда у вас есть прям переходы, которые вы хотите сделать, может быть смысл использовать функцию. Но если такой семантики не наблюдается, лучше написать внятный обычный скучный код. Коллегам не придётся задумываться, что это за функция и почему её надо использовать. Я бы никогда её не юзал. И хотя пост про то, что так не надо, некоторые из вас про неё не знали и обязательно станут пихать куда не стоит. Окститесь!! @thisnotes. Patreon, newsletter. Спасибо Artyom Garkavy и niki4smirn.
2 368
9
Фиксируем результаты. Некоторые вещи мне не помогут писать посты. Но мне было интересно узнать, откуда у меня аудитория, например. • География (>560). РФ 65%, 11% Беларусь, несколько ожидаемых для меня стран одинакового размера (Сербия, Польша, UK по паре процентов). Чуть больше на остальную европу и столько же на остальной мир (по 8%). • Род занятий (≈560). 86% разработчики. Ещё 5% — ML-enjoyers. В остальном либо очень мало, либо непонятно кто. • Опыт (≈570). Тут всё согласно нормальному распределению (что интересно, учитывая произвольность выбранных интервалов). Большинство (26%) 3-5 лет. По 20% на 1-3 и 5-10. По 14% на <1 года и 10-20 лет. И 6% имеют >20 лет. Подтвердил ожидания. Приятно, что вы разные: молодые неопытные и взрослые видавшие коллеги. • Грейд (≈560). 8% не работают. Я надеюсь, это ваш осознанный выбор. Столько же студентов/стажёров и джунов. 32% middle. 29% senior. Всё до этого момента выглядит ожидаемо. 6% подписчиков переросли senior (уважаемо, особенно если вы не просто себе лычку выбили). Порядка 6% — руководители (в основном IC, но есть и пару M2+, и даже один C-level, кто бы вы ни были). Фактически получается, что аудитория у меня всё-таки больше опытная, чем неопытная. Это конечно хорошо, но возможно с толканием базы надо быть осторожнее. • Размер компании (545). Не то чтобы это радикально важно, но даёт примерную картинку, насколько разные инженерные практики вы видите. Потому что компания размером 50 явно отличается от компании в 20к человек. Хотя и одна компания в 20к может радикально отличаться от другой компании в те же 20к. Значит вы разнообразные ещё и в самом опыте, и в проблемах, с которыми приходится сталкиваться. 23% в супергигантах каких-то. Почти 40% в небольших компаниях до 1000 человек. Остальные в серединке. • ЯП (520). Ожидаемо, большинство из вас трогает C++ (75%), C (21%), Python (47%) и Go (21%). Остальное поменьше. Rust всего 7%. Молодой ещё видимо. Java/Kotlin и Js/Ts по 10%. На Cobol никто не пишет. Слава богу. • ЯП интересы (≈470). Rust увлекает почти половину подписчиков (меня пока нет). Остальное +/- матчится с тем, что фактически используется. • Сфера (≈550). Половина — бэкендеры. Всё остальное в меньшинстве. Получается, средний подписчик — C++ бэкендер. Это довольно необычное сочетание для мира разработки. И я такой же. И такая комбинация мне очень нравится. Хорошо, что мы друг друга нашли. • Интересы (≈460). >40 % — backend. ≈30% — DB. 56% — low-level performance (значит можно и даже нужно больше уделять этому внимания). 38% конкретно backend performance (и сюда). 54% concurrency (и сюда!!). Пятая часть подписчиков ещё интересуются engineering management (значит я буду время от времени что-то про это писать, но не увлекаться). • Карьерная задача (≈510). 1/10 ищет первую работу. Успехов вам. 1/4 растёт до senior. Если будете делать правильные вещи, то получится достаточно быстро. Тут важно быть надёжным работягой и не подводить важных людей. Вы этому научитесь. 13% хотят вырасти дальше senior. Я тут концептуально понимаю, как это, но на практике пока не наработал. Давайте разбираться вместе. 8% хотят двигаться в сторону EM и дальше (см. канал Андрея и его community). 7% и 14% процентов хотят в бигтех или более технический домен. Значит вам нужно понять, чего ждут от хорошего кандидата и пойти усиленно над этим работать. Если не понимаете, что надо, приходите ко мне поговорить. 1/5 кайфует от жизни. Рад за вас! • Уровень понимания (≈490). 1/4 понимает всё. 45% тратит некоторые усилия на вникнуть. То есть не прям очевидно, но достаточно понятно. 1/5 чуть сложнее. Улавливают концепции, но есть сложности с деталями. Меньшинству очень сложно. Приходите с вопросами, чего вы! 5% шутников не вникают, потому что им не интересно. Ну штош! Получается, что большинство понимает всё довольно успешно. Варианта 2: либо я пишу очень понятно (круто); либо топики базовичковые (надо грузить вас чем-то более сложным). Повторим когда-нибудь, когда вас станет гораздо больше. Будем думать, как это применять теперь мощно.
2 501
10
Спасибо большое!
1 137
11
На каком уровне ты читаешь мои посты?
1 136
12
Что ты сейчас пытаешься улучшить в своей карьере?
1 116
13
Личные интересы вне языков программирования (mulitple):
1 011
14
Чем в основном занимаешься?
985
15
Языки программирования, которые интересны вне работы (mulitple)?
917
16
Основные языки программирования на работе (multiple)?
905
17
Какой размер вашей компании?
898
18
Ваш текущий уровень/грейд в текущей компании?
901
19
Сколько у вас коммерческого опыта (за деньги)?
909
20
Ваш профиль?
917