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

Решил поделиться своим топом цитат, возможно, они найдут отклик и у вас!

"Все проблемы в computer science можно решить ещё одним уровнем абстракции… Кроме проблемы слишком большого количества уровней абстракций" — Батлер Лэмпсон

"В теории нет разницы между теорией и практикой, но на практике есть" — Йоги Берра

"Некоторые проблемы лучше не решать, а избегать" — Тони Хоар

Делитесь в комментариях своими любимыми цитатами, которые чаще всего используете в работе!

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

В сентябре мы с Сашей записали совместный подкаст, где глубоко погрузились в мир языка программирования Go!

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

Получилось достаточно интересно, посмотреть наш подкаст можно по ссылке: https://youtu.be/ds_7PG6JOXY?si=2Dc34H5o1fMD4QE3

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

🚀Отказоустойчивость кеш-слоя в микросервисной архитектуре

📅 29 октября в 19:00 по МСК пройдет бесплатный открытый урок по паттернам отказоустойчивости в микросервисной архитектуре на Go!

На отрытом уроке узнаешь:
- Как искать «лавины» (Cache Avalanche), «грозовые стада» (Thundering Herd) и проблемы с согласованностью данных, а также как устранять их с помощью Single Flight, jitter и многоуровневого кеширования
- Как поддерживать актуальность данных: от простого TTL до активной и событийной инвалидации
- Как выбирать стратегию вытеснения данных (LRU, LFU) под конкретную нагрузку приложения
- Как разбираться в плюсах и минусах подходов к согласованности: Write-Through, Compare-and-Swap
- Как мониторить здоровье и эффективность кеша, чтобы система заранее оповещала о проблемах

Зарегистрироваться можно по ссылке

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

В сентябре с ребятами из Go To IT записали совместный подкаст о программировании и развитии скиллов в программировании!

В подкасте обсудили карту роста программиста, собеседования программистов, еще поговорили о разнице курсов и ВУЗов, а также разобрали EdTech изнутри на примере нашей школы по программированию.

Получилось достаточно интересно, посмотреть наш подкаст можно по ссылке: https://youtu.be/ThRojDkU06s

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

🚀Записал отдельное видео про пакет unsafe в Go

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

Также это видео будет полезно тем, кто хочет посмотреть, как абсолютно базовые операции можно выполнять под другим углом и зачем это нужно. Например, разобрав XOR-связные списки или tagged pointers.

Посмотреть видео можно по ссылке: https://youtu.be/6mTv1e8au9c

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

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

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

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

И вот, все эти крутые скиллы – просто растворяются, а интервью пройдено не так хорошо или совсем провалено!

Как так получается, что человек, способный строить сложные системы, не может *ясно* и *доступно* объяснить свою мысль? Это же не проблема отсутствия знаний, а чего-то другого.

📌 Давайте вместе подумаем, как таким инженерам помочь научиться транслировать свои мысли просто и понятно? Делитесь мыслями и советами в комментариях, а также встречали ли вы подобные ситуации в практике?

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

💭 Есть мнение, что рынок переполнен программистами, которые вообще не знают основ Computer Science. И, мол, без этих знаний они — не настоящие программисты.

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

Но вот вопрос: а всем ли это нужно на самом деле?

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

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

А вот в случае со сложными системами — например, с высокими нагрузками или непростой бизнес‑логикой — тут, да, без серьёзной базы никуда. Как правило, в таких проектах углублённые знания просто необходимы!

А вы как считаете? Пишите в комментариях!

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

У меня есть очень забавная история из собеседования кандидата в Тинькофф, как-то в прошлую мою команду проходил собеседование С++ разработчик.

Собеседование идет своим чередом, все как обычно. И тут, уже под конец, кандидат с гордостью заявляет: я — контрибьютор ядра Linux! А после собеседования он прислал ссылку на свой пулл-реквест.

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

И вот теперь вопрос к вам: как думаете, стоило ли кандидату упоминать об этом 'опыте' на интервью? 😅

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

Недавно мы организовали митап по backend разработке — в этом видео рассказываю, сколько времени это заняло, с какими сложностями столкнулись и во сколько все обошлось!

Если планируете своё событие — думаю, что будет полезно! Посмотреть видео можно по ссылке: https://youtu.be/1RxnR78Ehyk

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

Ищем технического консультанта с обширным опытом программирования для работы с нашим учебным проектом balun.courses. Ваша задача — помогать людям выбирать подходящие образовательные программы, консультировать по техническим вопросам и делиться экспертизой.

Нам нужен человек, который:
- любит делиться знаниями и отвечать на вопросы;
- умеет объяснять сложные технические вещи простым языком;
- имеет значительный опыт в программировании (желательно на Go);
- понимает, как выбирать обучение и что важно для развития карьеры в программировании.

Мы предлагаем:
- фиксированную оплату + процент от результата;
- доступ ко всем нашим образовательным продуктам;
- гибкий график и возможность совмещать с основной работой.

Если вы любите делиться знаниями и хотите присоединиться к нам или узнать подробности — пишите мне в Telegram: @vladimir_balun

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

В сентябре с Камилем записали совместный подкаст о языке программирования Go!

В подкасте обсудили:
- историю развития языка
- переход с других языков программирования на Go
- плюсы и минусы Go для компаний и разработчиков
- собеседования и требования к кандидатам
- рынок ванаксий для Go разработчиков

Получилось достаточно интересно, посмотреть наш подкаст можно по ссылке: https://www.youtube.com/watch?v=3_-SUou_gKI

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

Представьте: сидим с коллегами, обсуждаем рабочие процессы. И тут говорят: "У нас в команде ревьюим только крупные изменения. А мелкие – сразу в мастер и вперед в продакшен!"

Понятно, есть свои плюсы у такого подхода: скорость разработки и так далее. Но!

Сколько раз бывало, когда одна-единственная строка кода приводила к полному отказу сервиса? К падению базы данных? К инциденту, на разбор которого уходит день, а то и больше!

Я не говорю, что ревью кода — это 100% гарантия от всех проблем. Конечно нет. Но если вы уже тратите время на проверку кода, если у вас есть процесс для соблюдения чистоты, эффективности и поиска ошибок… Тогда почему бы не ревьювить все?

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

Как думаете? Стоит рисковать или каждый пулл-реквест, даже самый крошечный, заслуживает итерации ревью?

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