🐚 Почему бэкендеру важно уметь в коммуникацию, а не только писать код

В блоге о работе в Яндексе вышла статья разработчика каталога Лавки. За четыре года он вырос до тимлида, понял, что это не его, и снова стал бэкендером. Но софт-скилы нужны не только руководителям.

Делимся инсайтами о том, как и зачем бэкендеру уметь в софты:

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

🟢 Распределять задачи с командой фронтенда и в процессе диалога находить границы зон ответственности

🟢 Собирать фидбэк от тестировщиков начиная с самых ранних этапов разработки. Ребята хорошо знают все сложные места и самые актуальные проблемы. Общение с ними сильно экономит ресурсы разработки

🟢 Строить экосистемное взаимодействие. У сервиса может быть несколько точек входа — например, в Лавке это Еда, Маркет и даже Go. Так что с ребятами из этих сервисов нужно общаться

🟢 Техлидить проекты, которыми занимаются несколько команд. А это значит, что придётся всё со всеми обсудить, свести людей и ничего не потерять… А потом ещё пойти и написать код. Для этого тоже нужно уметь и любить коммуницировать с коллегами

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

🔶 Читайте полную статью в блоге

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

📺 Продуктовый рост vs деградация запросов

Рост количества данных не должен сильно снижать производительность. В шортсе Андрей Колнооченко, разработчик ядра Диска, разбирает, как проектировать индексы под реальную нагрузку: от выбора типа (hash vs B-tree) до оценки занимаемой памяти.

✂️ Это отрывок из видеопроекта Road to Highload: в нём инженеры Яндекс 360 делятся опытом создания архитектуры высоконагруженных систем. Смотрите все выпуски по ссылкам:

🟢 Сайт проекта
🟢 VK Видео
🟢 Ютуб

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

🧠 Как спасти мозг разработчиков от когнитивных перегрузов

Привет! На связи Роман Елизаров, руководитель отдела улучшения опыта разработчиков в Техплатформе Городских сервисов Яндекса. Я много лет работал над языком Kotlin, а сейчас занимаюсь тем, что модно называть Developer Experience. DX — это забота о программисте: чтобы ему было удобно, комфортно, быстро и понятно.

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

🔍 Отмотаем индустрию на 26 лет назад

В 2000-х Java оказалась идеальным языком для монолитов: спасибо рантайму (JVM) и строгой типизации. Если возникала ошибка, то падала не вся система, а только один запрос.

Но это породило проблему — тонны boilerplate-кода (геттеры, сеттеры, шаблоны обработки исключений). Этот когнитивный шум заставлял разработчиков постоянно продираться сквозь заросли кода к сути ценой их времени и сил. Всё равно что прикладывать пропуск к каждому турникету и двери в офисе.

🚀 В воздухе витал ветер перемен

В 2010‑х появился Kotlin. Его успех построен на простом принципе: экономить энергию и силы разработчика.

Он решал фундаментальные боли вроде NullPointerException, предлагал полную совместимость с Java и добавлял фичи экономно — только там, где это критически важно (как с дата-классами). Язык делал код выразительным, а не шаблонным.

Почему Kotlin взлетел на Android? Команда Google просто попробовала его в работе. Им понравилось, как язык бережёт их время и силы. Объявление на Google I/O 2017 о поддержке Kotlin вызвало самые громкие овации разработчиков за весь кейноут.

🦾 Платформа как язык организации

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

Хорошая платформа, как и хороший язык, снимает с разработчика рутину и инфраструктурные заботы. Плохая — становится источником постоянной головной боли.

❇️ Мы в Яндексе боремся с классическими антипаттернами:

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

🟢 Медленные процессы. Если создание сервиса занимает часы, DX стремится к нулю.
Решение: постоянный мониторинг метрик и оптимизация

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

❇️ Что сделать, чтобы улучшить DX:

🟢 Анализируйте потраченное время от идеи до работающего кода в продакшене

🟢 Создавайте эталонные пути для типовых задач (создание сервиса, деплой, тесты)

🟢 Посчитайте, сколько инструментов должен знать разработчик в вашей команде. Подумайте о том, что можно убрать или объединить

🟢 Измеряйте метрики опыта разработчиков

🟢 Ускорьте циклы фидбэка: быстрые тесты, мгновенные превью-окружения, подсказки в IDE

Разработчик должен думать только о своей бизнес-задаче, а не о шаблонном коде и инфраструктуре.

🔶 Это только часть того, что я рассказывал в рамках доклада на Joker 2025. Посмотреть запись целиком можно на ютубе и в VK Видео.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend