"Владимир Балун" — @vladimir_balun_programming Telegram-kanali

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

9 Oct, 10:32

AI-инструменты в работе тимлида – открытый урок 12 октября

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

12 октября, в понедельник, в 19:00 мск покажем, как использовать AI в повседневной работе тимлида и получать ответы, с которыми можно работать.

На конкретных задачах разберём:

1️⃣Как формулировать запросы и передавать контекст, чтобы получать полезные ответы вместо нейрослопа

2️⃣Как готовить встречи: собирать повестку, фиксировать договоренности и выделять следующие шаги

3️⃣Как готовиться к обратной связи и сложным разговорам с сотрудниками: продумывать формулировки и ход обсуждения

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

Урок проведет Александр Пряхин, технический руководитель в Авито Подработка, а зарегистрироватсья на него можно по ссылке: https://balun.courses/open_lessons/teamlead

Кто я | Навигация | Спасибо

1.5k 0 17 2 9

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

7 Oct, 15:11

Увидел комментарий:

"У меня 30 лет опыта и полтора года без работы. Более 10 языков программирования и большинство баз данных. Всю жизнь учился, получается зря"

И задумался: а что вообще значит "знать язык программирования"? Я в IT, конечно, не 30 лет, но тоже не мало, около 8 лет уже получается. Начинал с C/C++, потом перешел Go. За карьеру писал и на других языках, сталкивался с разными базами данных, фреймворками и технологиями. Но если меня сейчас спросить, какие языки я действительно знаю, список будет не очень длинным.

Например, Go - да. А вот про C/C++ я бы уже так уверенно не сказал. Хотя когда-то писал на них много и очень хорошо знал многие нюансы и особенности. Но за это время появились новые стандарты, изменились подходы, часть особенностей забылась, да и в продакшене я их давно не использовал.

Поэтому я всегда осторожно отношусь к формулировкам вроде "знаю 10 языков программирования". Можно ли иметь опыт работы с 10 языками? Конечно. Можно ли написать на них программу или вспомнить синтаксис? Тоже да. Но глубоко знать 10 языков одновременно - это уже совсем другая история, как по мне.

❗️Для меня знание языка - это не только синтаксис. Это понимание экосистемы, инструментов, типичных ошибок, новых возможностей и того, как этот язык используется сегодня, а не несколько лет назад. Поэтому, как правило, чем больше у человека опыта, тем реже я слышу фразу "я знаю 10 языков программирования". Обычно говорят проще: сейчас моя основная экспертиза вот здесь, а писал я еще на том-то и том-то.

А как вы считаете, сколько языков можно действительно знать одновременно?

Кто я | Навигация | Спасибо

2.3k 0 13 19 54

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

6 Oct, 15:55

Backend Systems | balun.courses dan repost

PostgreSQL тоже иногда проходит путь Джейкоба из первой части «Сумерек» в последующие.

Главное – не пытаться прокачать его первым решением, которое пришло в голову :)

Собрали несколько вариантов «можно так / но лучше так» для ситуаций, которые регулярно встречаются в проде.

*Ненавязчиво напоминаем, что 13 октября стартует наш курс по PostgreSQL. Стоимость обучения увеличится через 8 часов*

2.4k 0 13 25

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

5 Oct, 11:48

💭 Сейчас все чаще слышу одну и ту же мысль: зачем читать книги, смотреть технические доклады или конференции, если можно просто спросить что угодно у ChatGPT?

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

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

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

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

Кто я | Навигация | Спасибо

2.7k 0 14 6 42

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

4 Oct, 16:15

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

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

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

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

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

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

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

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

Кстати, завтра у нас в школе стартует курс по Observability от Виталия Лихачёва. Если тема эксплуатации систем, расследования инцидентов, метрик, логов и трейсов вам интересна - можете посмотреть программу по ссылке: https://balun.courses/courses/observability

Кто я | Навигация | Спасибо

Balun.Courses — вся база по Observability

Глубокий курс о том, как поставлять логи, метрики, трейсы, делать информативные дашборды, быстро устранять инциденты и правильно интерпретировать данные. Преподает SRE из крупнейшего TravelTech

2.7k 0 12 1 40

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

2 Oct, 11:47

💭 Недавно получил комментарий под анонсом одного из новых образовательных продуктов по ИИ - суть была примерно такая: "у вас не хватает знаний в этой области, чтобы этому учить".

И знаете, что самое интересное? Автор комментария прав, потому что лично у меня действительно нет экспертизы во всех направлениях, которые есть сегодня в нашей школе. Мне кажется, многие до сих пор воспринимают Balun.Courses как историю про одного преподавателя, который сам придумывает программы, записывает все лекции и ведет все курсы. Но на практике мы уже давно так не работаем. Во-первых, это физически невозможно. Во-вторых, я не считаю правильным учить людей тому, в чем сам плохо разбираюсь.

Лично я веду только несколько направлений: Go, System Design и небольшие ответвления. Все остальное создают и ведут преподаватели, которые разбираются в своих темах гораздо лучше меня. Именно поэтому у нас есть отдельные эксперты по Kafka, Observability, AI и другим направлениям. Если появляется новая тема, то мы не пытаемся срочно стать экспертами в ней сами, а ищем сильных практиков, которые уже много лет работают с этой технологией в реальных проектах.

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

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

Кто я | Навигация | Спасибо

2.7k 0 7 1 62

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

1 Oct, 13:47

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

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

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

Часто встречаются графики, которые показывают только симптомы, но не помогают найти причину. Например, видно, что выросло время ответа сервиса. Хорошо. А дальше что? Какой ендпоинт виноват? Какие пользователи затронуты? Это проблема базы данных, кэша или внешнего сервиса?

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

❗️В какой-то момент становится понятно, что проблема не в нехватке графиков. Проблема в том, что во время инцидента команда должна быстро ответить на несколько простых вопросов: что сломалось, когда сломалось, кого затронуло и где искать причину. Если существующие метрики, логи и алерты не помогают получить эти ответы, то неважно, сколько их у вас — десять или десять тысяч. Именно поэтому observability - это не про Grafana, Prometheus или OpenTelemetry сами по себе. Это про способность понимать состояние системы и быстро находить причины проблем, когда что-то идет не так.

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

Кто я | Навигация | Спасибо

2.9k 0 15 1 26

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

30 Sep, 11:04

💭 Заметил, что за последние годы записал довольно много материалов по System Design

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

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

Посмотреть можно по ссылке: https://youtu.be/wabfZC1ciNE?si=2bX-kUqK2U8nmbXk

Кто я | Навигация | Спасибо

3.2k 0 47 30

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

29 Sep, 10:48

💭 Не могу не поделиться одной мыслью, которая пришла мне в голову на прошлой неделе

Ходил на подкаст к Avito - обсуждали Go с разных сторон. Скоро выйдет, но поделиться хотел немного другим наблюдением.

Почему меня вообще туда позвали? Когда ребята написали с предложением записать подкаст, они сослались на другой подкаст про Go, который я записал во время конференции Стачка. А на тот подкаст меня позвали во многом благодаря докладу про unsafe в Go, который я рассказывал на той же Стачке.

Получается забавная многоходовка: если бы не поехал тогда с докладом, не было бы того подкаста. Не было бы того подкаста - не было бы приглашения от Avito на новый подкаст. Самое интересное, что ни доклад, ни тот подкаст не дали какого-то мгновенного результата. Видео набрало несколько тысяч просмотров - и все. Можно было бы сказать: "ну и зачем столько времени потратил?"

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

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

Кстати, не могу не сказать: если хотите записать совместный подкаст, интервью или сделать какую-то коллаборацию на YouTube - пишите в личку @vladimir_balun, буду рад обсудить!

Кто я | Навигация | Спасибо

3.5k 0 11 2 52

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

26 Sep, 13:25

balun.courses dan repost

00:13

3.6k 0 0 4 22

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

26 Sep, 12:04

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

Мол, что там знать? Выучил синтаксис, написал несколько сервисов - и все. И чаще всего такое говорят люди, которые либо вообще не пишут на Go, либо написали на нем совсем немного кода.

На мой взгляд, это утверждение одновременно и правда, и нет.

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

Потому что каким бы простым Go ни казался на первый взгляд, внутри него огромное количество нюансов и особенностей. Планировщик. Горутины. Сборщик мусора. Аллокатор. Escape Analysis. Дженерики. Итераторы. Weak поинтеры. Финализаторы. И еще множество вещей, про которые многие разработчики даже не задумываются до тех пор, пока не сталкиваются с реальной задачей или проблемой производительности.

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

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

Кстати, если вам интересно разобраться во всех этих нюансах не по отдельным статьям и видео, а системно, то как раз 29 сентября начинается уже 7-й поток курса «Глубокий Go». Там подробно разбираем устройство языка, память, рантайм, планировщик, сборщик мусора и другие вещи, понимание которых часто помогает писать более предсказуемый и эффективный код.

Кто я | Навигация | Спасибо

3.9k 0 9 11 28

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

25 Sep, 15:52

💭 Когда я переходил с C++ на Go, первое время постоянно ловил себя на одной и той же мысли: "здесь же можно сделать эффективнее"

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

И самое интересное - часть этих привычек я сначала автоматически переносил в Go.

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

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

Это не значит, что в Go можно забыть про память и производительность. Наоборот. Когда приложение начинает упираться в CPU, GC или память, понимание того, как все это работает внутри, становится очень полезным. Просто важно не оптимизировать то, что еще не доказало, что является проблемой.

И, наверное, это одна из самых полезных вещей, которые можно перенести из C++ в Go: не сами привычки оптимизации, а понимание того, что именно стоит оптимизировать и когда.

Кто я | Навигация | Спасибо

3.3k 0 7 4 52

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

22 Sep, 21:05

🚀 Напоминаю, что уже в эту субботу, 26 сентября, проведем бесплатную онлайн-конференцию для backend-разработчиков под кодовым названием #РАЗНЕСИ_СОБЕС

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

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

Всем участникам будут доступны запись и конспект конференции, а также среди участников онлайн разыграем: mock-собеседование от it-interview.io и два места на любой курс или интенсив школы

Регистрация по ссылке: https://balun.courses/interview_conf

Кто я | Навигация | Спасибо

3.5k 0 16 2 23

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

21 Sep, 21:36

💭 Периодически сталкиваюсь с тем, что после отказа на собеседовании разработчики начинают искать проблему в себе, например "чего-то не знаю" или "не дотягиваю"

Порой это действительно так. Но далеко не всегда.

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

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

Ссылка: https://youtu.be/jYhNLT9TPjE

Кто я | Навигация | Спасибо

3.9k 0 11 7 31

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

17 Sep, 14:54

00:28

Video oldindan ko‘rish uchun mavjud emas

Telegram'da ko‘rish

Avito.Tech.Conf уже совсем скоро

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

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

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

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

Кто я | Навигация | Спасибо

4.4k 0 13 2 15

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

16 Sep, 12:33

💭 Недавно выложил видео со своего выступления на конференции про базу продуктивности и эффективности для IT-специалистов

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

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

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

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

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

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

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

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

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

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

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

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

Кто я | Навигация | Спасибо

3.9k 0 12 2 17

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

16 Sep, 12:29

💭 Недавно выложил видео со своего выступления на конференции про базу продуктивности и эффективности для IT-специалистов

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

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

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

Но всё это — надстройка.

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

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

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

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

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

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

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

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

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

Если ещё думаете, приходить или нет — мест осталось не так много. Ссылка будет ниже.

1 0 0

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

15 Sep, 12:21

🚀 26 сентября проведем бесплатную онлайн-конференцию для backend-разработчиков #РАЗНЕСИ_СОБЕС

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

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

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

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

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

Кто я | Навигация | Спасибо

3.4k 0 24 3 23

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

14 Sep, 13:19

💭 На выходных ходил в поход в горы Архыза

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

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

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

Кто я | Навигация | Спасибо

3.6k 0 13 4 80

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

11 Sep, 11:09

💭 Постоянно сталкиваюсь с тем, что некоторые разработчики не совсем верно понимают, какие задачи решает репликация

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

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

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

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

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

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

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

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

Кто я | Навигация | Спасибо

3.9k 0 12 9 30

Купить живой трафик

Telegram Analytics

SearcheeBot

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

Kanal geosi va tili

Toifa

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8 690

Kanalda mashhur

Sayt tili

Купить живой трафик

Telegram Analytics

SearcheeBot

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

Kanal geosi va tili

Toifa

8 690

Kanalda mashhur