TGViewer
Channel Public Channel
Владимир Балун

Владимир Балун

@vladimir_balun_programming

Канал Балун Владимира - C++/Go разработчика из BigTech. Здесь вы найдете глубокие знания и материалы по программированию, личные истории и лайв-контент.

Сотрудничество: @vladimir_balun
Subscribers
8.61K
Photos
456
Videos
49
Links
502
Recent Posts 17 shown
Post #871 1.69K
Avito.Tech.Conf уже совсем скоро

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

Среди тем конференции:
- как меняется работа команд в эпоху AI-агентов
- как не превратиться в «эффективного менеджера» в плохом смысле этого слова
- когда стоит отказаться от стабильности и сделать ставку на собственные цели
- как расти без постоянного увеличения штата

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

Если ещё не видели программу - вся информация и регистрация по ссылке

Кто я | Навигация | Спасибо
  • 🔥 5
  • 👍 4
  • ❤ 3
  • 🏆 1
Post #870 1.93K
💭 Недавно выложил видео со своего выступления на конференции про базу продуктивности и эффективности для IT-специалистов

Под ним увидел интересный комментарий:

«О какой продуктивности и эффективности вообще может идти речь, если у меня болит спина, и я постоянно чувствую себя уставшим?»


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

Но все это - по моему мнению, надстройка.

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

Поэтому я смотрю на продуктивность как на несколько уровней.

Первый уровень - базовый лайфстайл. Сон, физическая активность, здоровье, восстановление, питание. Не обязательно превращаться в биохакера и жить по секундомеру. Но базовые вещи со здоровьем должны быть в порядке.

Второй уровень - организация работы. Приоритеты, планирование, управление вниманием, борьба с постоянными переключениями контекста.

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

Возможно, стоит начать с более простого вопроса: хватает ли вам сна и энергии, чтобы вообще качественно работать?

Кстати, уже в эту субботу пройдет наш офлайн-тренинг по soft skills для IT-специалистов в Москве. Тему здоровья, энергии и восстановления мы там разбирать не будем, а вот различные подходы к продуктивности и эффективности, приоритизации, постановке целей, принятию решений и коммуникации будем разбирать подробно и сразу отрабатывать на практических кейсах.

Если еще думаете, приходить или нет - мест осталось не так много: https://balun.courses/softskills

Кто я | Навигация | Спасибо
  • ❤ 5
  • 👍 3
  • 🔥 3
  • ⚡ 1
  • 💯 1
Post #867 2.12K
🚀 26 сентября проведем бесплатную онлайн-конференцию для backend-разработчиков #РАЗНЕСИ_СОБЕС

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

Что получите:
• потенциальные вопросы с собеседований
• понимание теории и инженерной логики за ответами
• аргументы и объяснения, которые ожидают услышать интервьюеры

Почему стоит прийти:
1. Соберете в одном месте вопросы, которые сейчас встречаются на собеседованиях. Без многочасового поиска по статьям, форумам и случайным подборкам из интернета.
2. Получите запись и конспект конференции. Можно будет вернуться к материалам перед поиском работы или подготовкой к очередному интервью.


Среди участников онлайн разыграем:
• mock-собеседование от it-interview.io
• два места на любой курс или интенсив школы

Если хотите подключиться онлайн или получить запись - зарегистрироваться можно по ссылке: https://balun.courses/interview_conf

Кто я | Навигация | Спасибо
  • ❤ 8
  • 👍 7
  • 🔥 2
  • ⚡ 1
  • 💯 1
  • 🏆 1
Post #865 2.4K
💭 На выходных ходил в поход в горы Архыза

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

Кстати, понял, что сокращение на работе не так страшно - в палатке жить вполне комфортно 😄

Ну а если интересен лайв-контент из поездок, спорта, работы над школой и просто жизни не так давно начал вести его по ссылке

Кто я | Навигация | Спасибо
  • ❤ 36
  • 🔥 28
  • 👍 9
  • 💯 4
  • ⚡ 1
  • ❤‍🔥 1
Post #864 3.21K
💭 Постоянно сталкиваюсь с тем, что некоторые разработчики не совсем верно понимают, какие задачи решает репликация

Очень часто можно услышать примерно такую логику:

«У нас база данных не справляется с записью, давайте сделаем несколько мастеров. Теперь запись можно будет распределить между ними, значит пропускная способность системы вырастет».


На первый взгляд звучит логично. Если серверов стало больше, почему бы просто не отправлять записи в разные узлы? Но проблема в том, что репликация устроена не так.

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

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

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

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

Поэтому когда слышу фразу «давайте добавим еще несколько мастеров и масштабируем запись», обычно задаю простой вопрос: сколько серверов в итоге должны обработать одну запись пользователя? Если ответ «все», то масштабирования записи здесь, скорее всего, не произошло.

Кто я | Навигация | Спасибо
  • 👍 15
  • ❤ 4
  • 🔥 4
  • ✍ 3
  • ⚡ 1
  • ❤‍🔥 1
  • 🏆 1
Post #863 2.96K
💭 В разработке редко бывают решения, где есть очевидно правильный ответ

Переписывать старый сервис или оставить как есть? Переезжать на новую базу данных или нет? Выносить функциональность в отдельный микросервис или пока рано?

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

Один из инструментов, который помогает сделать принятие решения объективным - Decision Matrix.

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

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

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

И это лишь один из инструментов принятия решений. Есть еще Pros & Cons, квадрат Декарта, а также различные методы, например правило 10/10/10, метод советника и другие подходы. Кстати, все эти инструменты мы подробно разбираем на тренинге по soft skills для разработчиков в Москве 19–20 сентября: https://balun.courses/softskills.

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

Кто я | Навигация | Спасибо
  • 🔥 7
  • 👍 6
  • ❤ 3
  • ⚡ 1
  • 💯 1
Post #862 2.69K
💭 Не так давно выступал на нескольких конференциях с докладом о том, как айтишникам больше успевать

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

Сейчас решил записать отдельное видео на эту тему. В нем я не просто разбираю отдельные техники вроде to-do листов, матрицы Эйзенхауэра или других способов приоритизации задач. Попытался собрать в единую систему разные подходы и принципы: таймбоксинг, закон Паркинсона, context switching cost, эффект Зейгарник и другие инструменты, которые помогают навести порядок в рабочих задачах и использовать их не по отдельности, а как часть одного процесса.

Посмотреть видео можно по ссылке: https://www.youtube.com/watch?v=dJLXfk0dcOo

Кто я | Навигация | Спасибо
  • 👍 14
  • ❤ 6
  • 🔥 4
  • ❤‍🔥 2
  • ⚡ 1
  • 💯 1
Post #861 2.82K
💭 Перед тем как появился хайп вокруг микросервисов, многим казалось, что все довольно просто

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

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

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

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

Именно поэтому сегодня все чаще говорят не про Prompt Engineering, а про AI Engineering. Как когда-то недостаточно было просто знать, например Docker, чтобы проектировать распределенные системы, так и сегодня недостаточно уметь писать хорошие промпты, чтобы создавать надежные AI-продукты.

Для тех, кто хочет разобраться в этой области глубже, 15 сентября у нас начинается отдельный курс инженерия AI-агентов. На нем мы разбираем не работу отдельных моделей, а разработку полноценных AI-систем: RAG, MCP, memory, observability, multi-agent архитектуры и другие темы, которые все чаще встречаются в реальных проектах.

Кто я | Навигация | Спасибо
  • 👍 13
  • ❤ 6
  • 🔥 4
Post #860 3.17K
💭 Самая опасная фраза в карьере - "мне и так нормально"

Недавно общался с коллегой, и он говорит: "Да у меня уже все нормально - хорошо зарабатываю, задачи интересные, работаю удаленно, жизнь удалась". И я с ним согласен - прямо сейчас у него действительно все хорошо. Более того, вполне возможно, что через 3-5 лет у него тоже всё будет хорошо и он вообще никогда не столкнется с серьезными проблемами в карьере.

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

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

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

Кто я | Навигация | Спасибо
  • ❤ 24
  • 💯 24
  • 👍 11
  • 🔥 4
  • ⚡ 1
  • 🏆 1
Post #859 3.38K
💭 Записал новое видео на тему, о которой в последнее время много думал

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

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

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

В видео подробно рассказываю, как отличить одно от другого и как сделать так, чтобы обучение действительно приближало вас к тем результатам, которые вы хотите получить. Посмотреть его можно по ссылке: https://www.youtube.com/watch?v=DkPSYiKq20o

P.S. если ваша текущая задача - подготовиться к System Design интервью или систематизировать знания по проектированию высоконагруженных систем, то уже 8 сентября у нас стартует 16-й поток курса по System Design. Будем разбирать реальные архитектурные кейсы, типовые вопросы с интервью и подходы, которые помогают уверенно проходить собеседования в сильные компании, присоединиться можно по ссылке: https://clck.ru/3VeVBH

Кто я | Навигация | Спасибо
  • ❤ 9
  • 👍 7
  • 🔥 6
Post #858 3.46K
💭 Уже видели анонс новой Avito.Tech.Conf?

26 сентября Авито снова собирает лидов, руководителей и всех, кто работает с людьми, процессами и развитием команд. Судя по программе, будет много актуальных тем: как меняется управление в эпоху AI, как расти без бесконечного найма, что происходит с инженерными командами сегодня. Плюс воркшопы, панельные дискуссии и возможность пообщаться с большим количеством людей из индустрии.

🎾 Кстати, в этом году Авито запартнерились с Buenos Padel на ВДНХ и приглашают участников конференции бесплатно поиграть в падел. Многие мои знакомые уже записались и говорят, что это отличный способ познакомиться и пообщаться еще до самой конференции в неформальной обстановке. Если давно хотели попробовать падел - хороший повод.

Если тоже рассматриваете участие, лучше не откладывать регистрацию: свободных мест обычно надолго не хватает.

Кто я | Навигация | Спасибо
  • ❤ 6
  • 👍 5
  • ✍ 3
  • 🔥 3
Post #856 3.4K
💭 Давно не делился книгами, которые читал в последнее время

Недавно добрался до книги Александра Фридмана "Делегирование. Результат руками сотрудников". Купил ее еще весной после одного из его тренингов по менеджменту, но до чтения руки дошли только сейчас.

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

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

Ну и, конечно, книга с автографом автора читается чуть приятнее 🙂

Кто я | Навигация | Спасибо
  • 👍 18
  • 🔥 7
  • ❤ 4
Post #855 3.29K
💭 Бывает такое, что смотришь на какое-нибудь обучение и вроде тема интересная, отзывы хорошие, программа выглядит сильной, но до конца непонятно, что находится внутри

Кто преподает? Как объясняют материал? Насколько глубоко разбираются темы? Есть ли практика или это просто набор лекций? И самое главное - подойдет ли обучение именно вам.

Поэтому с 1 по 8 сентября мы проводим день открытых дверей в Balun.Courses. В течение недели откроем доступ к материалам наших программ: покажем записи занятий и фрагменты лекций, поделимся полезными видео по Go, System Design, микросервисам, Kafka, Observability, менеджменту и другим направлениям, познакомим с преподавателями и форматом обучения, а также покажем реальные кейсы и результаты студентов.

🎁 И еще один приятный бонус: с 1 по 8 сентября действует дополнительная скидка 15% на все курсы и интенсивы школы.

Посмотреть материалы и познакомиться со школой можно по ссылке: https://balun.courses/open_day

Кто я | Навигация | Спасибо
  • 👍 7
  • ❤ 3
  • 🔥 3
Post #854 3K
💭 Не так давно, когда открыл аналитику YouTube-канала за год, задумался о такой штуке, как мультипликативный эффект

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

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

Потому что есть действия с линейным эффектом: перестал делать - перестал получать результат. А есть действия с мультипликативным эффектом: работа давно сделана, а ее результат продолжает приносить пользу.

А какие примеры мультипликативного эффекта в своей жизни замечали вы?

Кто я | Навигация | Спасибо
  • ❤ 18
  • 👍 14
  • 🔥 5
Post #853 3.29K
💭 Иногда самые очевидные решения оказываются совсем не такими простыми, как кажутся на первый взгляд

Когда я работал в Яндексе и занимался развитием системы трейсинга, через нее проходило около 10-11 ГБ входящего трафика в секунду. Чтобы эффективно писать такой объем данных, мы батчевали спаны большими пачками - примерно по 60-70 тысяч штук и записывали их в ClickHouse. ClickHouse отлично работает с большими вставками, поэтому такой подход позволял эффективно использовать ресурсы и получать хорошую производительность.

Но была одна проблема.

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

На первый взгляд решение выглядит очевидным.

«Давайте поставим Kafka между коллекторами и ClickHouse».

Коллекторы будут писать данные в Kafka, Kafka обеспечит надежное хранение, а отдельные сервисы будут вычитывать сообщения большими пачками и записывать их в ClickHouse. Мы получим и надежность, и большие батчи для записи.

Красиво. Логично. Понятно.

Но когда мы начали считать ресурсы под такую схему, оказалось, что только для Kafka потребуется что-то около одной-двух тысяч CPU-ядер. Не говоря уже про память, диски, сеть и стоимость эксплуатации всего этого хозяйства. В этот момент становится понятно, что между фразой «давайте просто добавим Kafka» и реальной системой лежит огромная пропасть.

Именно поэтому мне всегда нравились инфраструктурные технологии. На презентациях все выглядит просто: поставили Kafka, подключили продюсеров и консюмеров - готово.

Но на практике вопросы обычно начинаются гораздо раньше:
• Нужна ли здесь вообще асинхронная обработка?
• Сколько ресурсов потребуется для эксплуатации такого решения?
• Какие дополнительные гарантии надежности даст Kafka именно в моей системе?

Часто оказывается, что самое сложное - не настроить Kafka, а понять, стоит ли ее использовать в конкретной задаче. Именно поэтому некоторое время назад мы решили сделать отдельный курс по Kafka для разработчиков.

Его ведет инженер с очень интересным опытом. С одной стороны, он несколько лет занимался построением и эксплуатацией стриминговых платформ в Райффайзен Банке и работал с крупными Kafka-инсталляциями на практике. С другой - сейчас он разрабатывает YDB Topics в Яндексе - систему, которая реализует Kafka API и выступает лог-брокером внутри экосистемы Yandex Cloud.

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

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

Кто я | Навигация | Спасибо
  • 👍 11
  • ❤ 3
  • ⚡ 3
  • 🔥 1
  • 🎉 1
  • 👨‍💻 1
Post #852 3.83K
💭Что отличает разработчиков, которые быстро растут в карьере, от тех, кто годами остается на одном уровне?

Сразу оговорюсь - это субъективное наблюдение. Я не проводил исследований и не собирал статистику. Это просто наблюдение за коллегами, знакомыми и новичками в IT за последние годы.

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

Зато у них почти всегда есть три другие вещи.

1️⃣ Первая - ответственность.

Как правило, они берут задачу и доводят ее до результата. Не ищут оправдания, не перекладывают ответственность, не рассказывают, почему что-то не получилось.

2️⃣ Вторая - инициатива.

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

3️⃣ Третья - мышление через бизнес.

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

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

А что, по вашему мнению, сильнее всего влияет на карьерный рост разработчика?

Кто я | Навигация | Спасибо
  • 👍 25
  • ❤ 13
  • 💯 10
  • 🔥 3
  • 👏 1
Post #851 3.7K
💭 За последние несколько лет курсов по System Design стало заметно больше

И это хорошо.

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

Когда я создавал свой курс по System Design, подобных продуктов было буквально несколько. Причем один из них был больше ориентирован на Data Science-направление (не буду здесь рекламировать конкурентов), а мне хотелось построить программу именно для разработчиков и инженеров.

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

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

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

Чтобы после обучения человек понимал: как анализировать требования, как подходить к проектированию системы, какие архитектурные паттерны существуют, какие компромиссы приходится принимать, как обосновывать свои решения и как проходить System Design-интервью.

❗️Конечно, эта систематизация не появилась из воздуха.

За последние годы мне довелось работать над высоконагруженными системами в Яндексе, Ozon, Т-Банке и Mail.ru. Например, в Яндексе я руководил развитием системы трейсинга с трафиком 11 ГБ/с, а также проводил System Design-интервью и сам их проходил. Именно этот опыт во многом лег в основу курса. 

Но не меньше на него повлияли сами студенты. За это время курс прошел уже 16 потоков. Практически после каждого мы что-то улучшали, добавляли новые темы, улучшали практику, меняли тесты, перерабатывали объяснения и учитывали обратную связь участников. Отдельные потоки проходили целые компании. Например, для Wildberries мы обучали более 100 разработчиков несколько раз, а многие работодатели до сих пор отправляют сотрудников на обучение за счет компании.

Наверное, именно поэтому большинство отзывов похожи между собой. Люди часто пишут, что впервые увидели System Design не как набор отдельных технологий, а как целостный процесс принятия архитектурных решений. Сегодня средняя оценка курса составляет 4,94 из 5, а 86,6% выпускников готовы рекомендовать его коллегам и друзьям.

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

Если вам близок такой подход, буду рад видеть вас на следующем потоке курса по System Design, который начнется 8 сентября. А еще на сайте есть демо-доступ - можно бесплатно потестить качество материала, не приобретая кота в мешке.

Также сейчас мы работаем над новым продуктом - AI System Design. Он будет посвящен проектированию AI-систем и интеграции AI-компонентов в существующие продукты. Этот курс буду вести не я, а отдельный эксперт с практическим опытом в данной области.

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

Кто я | Навигация | Спасибо
  • ❤ 11
  • 👍 8
  • 🔥 4
  • ⚡ 2
  • 🎉 1
  • 🏆 1
Older posts →

About this channel

How can I read @vladimir_balun_programming without a Telegram account?
TGViewer shows the public web preview Telegram publishes for Владимир Балун: recent posts, photos, videos and the subscriber count, with no app, login or account.
How many subscribers does Владимир Балун have?
Владимир Балун (@vladimir_balun_programming) has 8.61K subscribers on Telegram, refreshed roughly every 30 minutes.
Does Владимир Балун know I viewed it here?
No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →