Привет, Хабр! Это Вадим из команды AvitoTech. Поговорить о программировании любите? Обновления обсудить, про подходы похоливарить, вот это вот все. Мы вот такое очень любим и даже вживую собираемся, чтобы поболтать на дринкапах.

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

Так вот, весной мы собрали в московском офисе более сотни разработчиков, чтобы обсудить самые актуальные для Go-комьюнити темы: начиная со сложностей при переходе на язык Go и заканчивая извечным вопросом о пользе хард- и софт-скиллов. Обсуждения были бурными и мы просто обязаны вас в них посветить.

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

Самые «горячие» темы:

• Карьерная ветка программиста: от Hello World до системного мышления

• Как правильно структурировать проект, чтобы всё не развалилось

• Почему софт-скиллы важнее хард-скилов и как их развить

• Кому и как легче вкатиться в GO после многих лет разработки на другом языке

• Продуктовый разработчик: как совместить технические навыки и продуктовое мышление

• Почему GO такой странный?

• LLM как помощник Go-разработчика: от автодополнения до промпт-инжиниринга

• «Прощай, ООП! Hello, Golang!»

• Как обеспечивать надежность и предсказуемость работы сервисов

Итоги обсуждений

Карьерная ветка программиста: от Hello World до системного мышления

Николай Губин, бэкенд-инженер в команде SLA

Виктор Куликов, тимлид в команде Pro-Vas

Причины

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

Мнения

На круглом столе сложилась по-настоящему домашняя атмосфера: как будто мы просто собрались с друзьями обсудить, что у кого болит. Участники открыто делились личными историями: как они вообще пришли в профессию, как сложно было сделать первый шаг и преодолеть ощущение, что «я ещё не готов». Много говорили о внутренних переходах — не по грейду в системе оценки, а по ощущению собственной зрелости. Как приходит понимание, что ты уже не просто middle, а что-то большее. Что ты начал думать о других, принимать решения, влиять на команду. И как важную роль в этом играют не только опыт и знания, но и окружение, доверие и осмысленные вызовы.

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

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

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

Выводы

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

Как правильно структурировать проект, чтобы всё не развалилось

Павел Стариков, бэкенд-инженер в команде Three Axes

Причины

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

Мнения

Тяжело выделить какие-то конкретные мнения. Беседа строилась непринужденно и никто не топил друг друга. Мы смотрели на различные варианты архитектур: плоские, слоеные, гексагональные, луковые, обсуждали их плюсы и минусы и в каких случаях стоит выбирать конкретную из них. Обсуждали важность изоляции и абстракций для тестируемости, а также как БД влияет на структуру проектов. Ребята за столом накидывали примеры из других языков и фреймворком, которые предоставляют свои шаблоны проектов из коробки. Говорили про важность архитектуры в разрезе простоты погружения в нее новых сотрудников — отсюда сделали вывод: как бы круто и технологично не был устроен твой проект, какая в этом разница, если, глядя на структуру, непонятно, что она делает, а чтобы понять предназначение, надо заглянуть в N файлов.

Выводы

• На разных стадиях проект может иметь разную структуру. Меняться — нормально.

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

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

Павел Комаров, бэкенд-инженер в команде Build Busters

Причины

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

Мнения 

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

Выводы

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

Почему софт-скиллы важнее хард-скилов и как их развить

Шамистан Алызаде, бэкенд-инженер в команде Data Quality

Причины

Этот вопрос был и — я уверен — будет актуален всегда: что важнее хард или софт? Чтобы сподвигнуть участников на дискуссию, тема специально сформулирована провокационно. Могу выдвинуть несколько мыслей, почему именно сейчас эта тема актуальна:

• усиление распределённой и удалённой работы. С развитием удалёнки и гибридных команд коммуникационные барьеры выросли: без «живого» офиса сложнее читать невербальные сигналы, быстро договариваться и выстраивать доверие. Поэтому софт-скиллы (эмпатия, активное слушание, умение фасилитировать обсуждения) выходят на первый план.

• рост междисциплинарности проектов. Go-команды всё чаще взаимодействуют с DevOps-специалистами, дизайнерами, продуктовиками и заказчиками. Успех проекта зависит не только от качества кода, но и от умения договориться о требованиях, разделить зоны ответственности, согласовать сроки и рисовать дорожные карты.

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

Мнения

• Soft > Hard

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

• Hard > Soft

Глубокие технические знания — основа качественного продукта; без них не «заточишь» систему под высокую нагрузку и не обеспечишь безопасность. Производительность Go-приложений определяется алгоритмами и архитеκтурными решениями, а не тем, как вы общаетесь. Чёткое владение инструментами (goroutines, каналы, профайлинг) позволяет быстро решать узкоспециализированные задачи. Портфель успешных проектов складывается из технических результатов: они более объективны, чем «мягкие» метрики.

Сторонники этой позиции подчёркивали: софт-скиллы естественным образом приходят со временем, а хард-скиллы требуют целенаправленного обучения.

• Баланс и симбиоз

Софт- и хард-скиллы дополняют друг друга: один без другого даёт невысокую эффективность. Хорошие софт-скиллы облегчают обмен знаниями и ускоряют обучение хард-скиллов внутри команды. Понимание своих технических ограничений (hard) помогает выбирать подходящие методы коммуникации и выстраивать процесс так, чтобы компенсировать договорённости (soft). Каждый человек уникален: нужно уметь видеть свои «слепые зоны» (soft) и планомерно прокачивать недостающие технические области (hard).

 Выводы

  Какого консенсуса (если он был) удалось достичь?

• Нельзя отдавать приоритет только одному типу навыков.

• Хард-скиллы объективно проще оценить и развить через литературу и курсы, но именно софт-скиллы часто являются «узким местом» в коммуникации и командном взаимодействии.

• Каждому участнику важно развивать способность к саморефлексии, чтобы увидеть собственные «слепые зоны».

  Какие рекомендации или решения были предложены?

• Внедрить регулярные «360°-reviews», где коллеги дают обратную связь не только по коду, но и по уровню эмпатии, готовности помогать и коммуникации.

• Провести серию воркшопов и мини-тренингов с внешним коучем по ключевым софт-скиллам: технике вопросов, управлению эмоциями, ведению эффективных ретроспектив.

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

• Предложили Коуч-дни  — практиковать приглашение профессионального Agile-коуча на день-два, во время которых он поможет выявить «узкие места» в коммуникации и разогнать «командный мотор».

• Личные журналы развития и поощрение ведения простого дневника: какие задачи дались особенно тяжело, где «застряли» и над какими софт-скиллами стоит поработать (умение задавать вопросы, спокойно воспринимать критику и так далее).

Кому и как легче вкатиться в GO после многих лет разработки на другом языке

Семен Эйгин, бэкенд-инженер в команде Vega

Тимур Хужин, бэкенд-инженер в команде Talent

Причины

При рассмотрении перехода на Go особый интерес представляет анализ именно soft-skills, а не технических аспектов. Наблюдения за разработчиками, осваивающими Go после многолетнего опыта работы, например, с PHP (часто это опытные возрастные специалисты с солидным стажем) или любым другим языком программирования, вызывают закономерный вопрос: с каким багажом и бэкграундом легче всего «вкатиться» в Go?

Эта тема остается актуальной, потому что раньше лишь немногие разработчики начинали писать на Go с нуля — большинство приходило в язык после долгих лет работы с Java, C++ и другими языками. Сейчас таких случаев стало еще больше, поэтому вопрос не теряет своей значимости.

Мнения

• Зачем вообще переходить на Go?

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

• Собеседования: можно ли устроиться в Avito бэкенд-разработчиком без знания Go?

Многие кандидаты переживают, получится ли пройти собеседование на их основном языке программирования — том, на котором они пишут сейчас. Возможен ли вход в Avito без опыта в Go? Ответ — да. У нас есть практика найма сильных инженеров, даже если они пока не работали с Go. Если вы покажете глубокие знания в разработке и потенциал к росту, вас могут взять с условием освоения Go в первые несколько месяцев работы.

Выводы

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

2. Всем одинаково тяжело вкатывать в Go. Освоение Go вызывает схожие трудности у разработчиков с разным бэкграундом. Особенно заметные сложности возникают у специалистов, привыкших к классической объектно-ориентированной парадигме (C Sharp, Java, C++). Главная проблема заключается в необходимости перестройки мышления и восприятия кода. На скорость адаптации существенно влияет и профессиональный опыт: молодым разработчикам, не имеющим многолетнего опыта работы с ООП, перестроиться проще. А вот опытным специалистам с 10-20 годами работы на одном языке объективно сложнее, так как их профессиональное мышление сформировано в другой парадигме.

Продуктовый разработчик: как совместить технические навыки и продуктовое мышление

Влад Гайденко, бэкенд-инженер в команде Spare Parts 3

Андрей Леонтьев, тимлид разработки в Авито Товары

Причины

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

Мнения

• Зачем посредники? Давайте напрямую!

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

• Аналитик — это святое, не трогать!

Ребята из энтерпрайза/проектной работы настаивают: пусть разработчик кодит, а требования собирает тот, кто в этом шарит. Иначе получается каша из недопонимания и костылей.

Выводы

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

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

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

Почему GO такой странный?

Михаил Шевченко, бэкенд-инженер в команде Bricks

Алексей Мичурин, бэкенд-инженер в департаменте разработки Services

Причины

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

Мнения

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

Выводы

Странные вещи в Go могут доставлять боль, но могут приносить и пользу при хорошем понимании их назначения. Идеи, заложенные в Go, вызревали десятки лет (около сорока), и, до того как воплотиться в Go, они получали развитие в экспериментальных языках — Newsqueak, Alef и Limbo. Проанализировав истоки языка, мы увидели, что необычные конструкции Go имеют глубокие корни и осмысленную философию. Это помогает преодолеть первоначальный дискомфорт от необычных идиом и научиться осознанно пользоваться языком, раскрывая его истинный потенциал. 

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

LLM как помощник Go-разработчика: от автодополнения до промпт-инжиниринга

Антон Киреев, тимлид в команде Corgi

Альберт Мухарамов, техлид в команде Shiba

Причины

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

• бурное развитие ИИ-инструментов. После появления ChatGPT, Copilot и других моделей разработчики стали активно экспериментировать с их применением. Возникает вопрос: где, собственно говоря, реальная польза, а где — просто тренд?

• Go догоняет по tooling'у. Язык очень лаконичный и минималистичный и именно поэтому интересно: как LLM могут вписаться в экосистему Go?

• рост интереса к повышению эффективности. Команды и компании ищут способы ускорить разработку без потери качества. LLM помогают автоматизировать рутину и потенциально становятся партнером при проектировании.

Для Go-сообщества эта тема актуальна потому, что открывает новые практики, влияет на подход к обучению, документации и ускоряет вход в проекты.

Мнения

• LLM как расширение мышления/памяти/знаний разработчика

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

• LLM — это пока что ненадежный костыль

Угрюмый лагерь скептиков поднимал вопросы о точности, доверии и применимости моделей в «боевых» проектах. Особенно на Go, где важна строгость, типизация и контроль. Они указывали, что модель может галлюцинировать (причем очень сильно), не учитывать контекст и создавать ложное ощущение уверенности в ответах.

• Промпт-инжиниринг как новый навык

Ещё одно мнение: успех использования LLM зависит от умения с ней взаимодействовать. Грамотно составленный запрос — ключ к полезному ответу. Go-разработчику стоит освоить базовые техники промпт-инжиниринга, даже если язык сам по себе минималистичен. Здесь важны точность формулировок и ясная структура задач. Здесь ребята аргументировали также тем, что если мы не будем этим пользоваться, то мы как разработчики станем неконкурентоспособны, ибо другие элементрано тупо перебивать нас.

Выводы

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

Помимо прочего, в ходе дискуссии мы поняли, что:

• не надо ждать чуда от первой попытки — стоит потратить время на обучение себя и команды: как формулировать запросы, как оценивать результат;

• использовать LLM для: генерации boilerplate-кода, описания функций, ускоренного прототипирования, ревью кода (с ограничениями) или документации;

• разделять зоны риска: критический код — руками и линтерами, а вспомогательный — с помощью LLM.

«Прощай, ООП! Hello, Golang!»

Владислав Чуйков, бэкенд-инженер в команде Billing.Arch

Владислав Колесников, бэкенд-инженер в команде Billing.Arch

Причины

• Go, в отличие от многих распространенных языков программирования, не реализует традиционное ООП. 

• Переход из других языков. Многие разработчики, особенно с опытом в Java, C++ или Python, пытаются применять привычные ООП-подходы в Go и сталкиваются с ограничениями или непривычными решениями. Это порождает дискуссии о том, насколько Go — «ООП-язык» и как правильно проектировать код на Go.

• Гибкость и ограничения. Go позволяет реализовать многие ООП-принципы (инкапсуляция, полиморфизм, абстракция), но делает это по-своему, что часто обсуждается в сообществе как преимущество или, наоборот, как недостаток.

Мнения

• Многие боятся переходить на Go из ООП-языков, ведь нужно заново «учиться» и привыкать к языку из-за его особенностей.

• ООП-подходы Go — осознанный минимализм против избыточности классики. Сторонники Go считают, что язык реализует «правильное» ООП — инкапсуляцию, абстракцию и полиморфизм, — но избегает наследования, которое часто приводит к ошибкам и излишней связанности. Go вынуждает проектировать более плоские, модульные системы, что ускоряет рефакторинг и снижает количество ошибок.

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

Выводы

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

• Для инженеров, которые только собираются переходить на Go, порекомендовали ознакомиться с объектной моделью Go и посмотреть статьи на данную тему.

• Важно не бояться пробовать новое, так как любой опыт позволяет становиться более профессиональным специалистом.

Как обеспечивать надежность и предсказуемость работы сервисов

Павел Лакосников, руководитель юнита в департаменте разработки Architecture

Денис Захаров, бэкенд-инженер в команде Partners

Причины

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

Роль SRE в Авито нет, однако сохранять деньги бизнесу по-прежнему нужно. Как тогда компания обеспечивает надежность и предсказуемость работы своих сервисов? Обсудили следующие подходы и инструменты:

• процессы, шаталити, реагирование на инциденты по зонам ответственности команды, дежурных;

• NFRs и трекинг надежности;

• платформенные способы обеспечения надежности (канарейки, авто-алерты, деплой-полиси, управление ресурсами);

• внутреннее обеспечение: как мы подходим к надежности внутри сервиса (кэш, асинхронщина);

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

Мнения

• Архитектура в целом важнее, чем структура сервиса.

• Надежность сервисов надо обеспечивать, внедряя множество технических приемов (RateLimiters, CurcuitBreakers, etc).

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

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

• Сохраняется бизнесовый подход на уровне проектирования: важно смотреть за контрактами SLA и управлять рисками.

• Отдать выстраивание надёжности на откуп специальным людям вроде DevOps’ов SRE или единственному разработчику FullStack.

Выводы

• Не везде процессы дежурств и обеспечения надежности зрелые.

• Стоит вкладываться в прозрачность надежности: откуда берутся требования и из-за почему они такие?

Итоги обсуждений

1. Рост начинается не с грейда, а с внутреннего запроса на развитие, новых зон ответственности и системного мышления.

2. Единого рецепта идеальной архитектуры не существует — важна читаемость и живость проекта.

3. Софт-скиллы не менее значимы, чем хард-, особенно в распределённых командах.

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

5. Продуктовое мышление усиливает разработчика и помогает говорить на одном языке с бизнесом.

6. «Странности» Go — это компромиссы, за которыми стоит осознанный дизайн.

7. LLM — полезный инструмент, который полезно интегрировать в рабочей процесс с должной аккуратностью.

8. Композиция в Go — не ограничение, а возможность проектировать проще.

9. Надёжность достигается не только кодом, но и культурой в команде.

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

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