Яндекс Практикум добавил модули по работе с ИИ во все курсы ИТ-профессий для начинающих
Мы дополнили все курсы из каталогов «Программирование» и «Анализ данных» модулями по работе с ИИ, чтобы наши выпускники не просто «пользовались нейросетями», а превращали их в инструмент профессионального роста — и были востребованы на рынке труда.
Теперь вы сможете:
Разобраться, как устроены нейросети, освоить основы промпт-инжиниринга и научиться подбирать подходящие инструменты.
Использовать AI для быстрого освоения новых технологий и поиска решений.
Применять нейросети для генерации материалов, планирования проектов и оптимизации учебного процесса.
Научиться решать профильные задачи с помощью инструментов искусственного интеллекта.
Со временем, сложность проектов только растет. Какие бы мы изменения в коде не делали, переходили на новые фреймворки, базы, языки или подходы, алгоритмическая сложность (то что в бизнес логике) будет становиться только выше. Технические улучшения максимум могут убрать случайную сложность, когда мы выбрали неверный или не самый эффективный инструмент, но если с точки зрения логики нужно выполнить 30 разных сценариев, мы их запрограммируем в любом случае независимо от выбранных технологий.
Фактически все за что мы боремся когда занимаемся архитектурой проекта, это возможность сделать так, чтобы эта сложность росла как можно медленнее. Потому мы добавляем абстракции (когда без них больно), откладываем принятие ключевых решений и делаем много всякого разного. Естественно все это с учетом требований по производительности, надежности и т.п.
Ниже 5 рекомендаций, по тому, как определить, что выстрелит, а что можно отложить на потом и не сильно париться с кодом.
Грамотное управление состоянием
Говорил, говорю и буду говорить. За всем многообразием принципов и шаблонов, в самой глубине скрывается то как мы работаем с эффектами и процессами (состояния и переходы). Умение видеть это добро в коде и правильно с этим работать это ключ к тому, чтобы система оставалась поддерживаемой и устойчивой к ошибкам на самом нижнем уровне, когда мы на код смотрим как на код.
Изолированная сложность
В любом проекте есть какие-то вычислительные функции, которые работают как черный ящик и ни с чем не связаны. Сюда например, можно отнести все математические функции. Насколько принципиально если внутри грязь и копоть? Практически без разницы, такой техдолг изолирован и не растит общую сложность системы. Его можно воспринимать как библиотечный код, который пришел из зависимостей. Такой код можно переписать в любой момент, когда это станет нужным (например нужно повысить производительность) и с таким кодом отлично справляются LLM.
Приоритеты слоев
Ошибки на уровне формирования моделей и их связей, решают намного больше чем ошибки допущенные при выводе этих данных в api или на фронтенде. Вывод это всегда терминальная стадия, его результаты никак не используются в коде, а вот модели и то как организованы связи, это основа всего, что пронизывает все приложение на самом глубоком уровне. Если тут накосячить, страдать будем в каждой точке сталкивания. Можно сказать что порядок приоритета такой:
модели + структура базы => обработчики (контроллеры, сервисная история) => вывод (сюда же переводы и работа со строками)
Публичные контракты (API)
Все что выставляется наружу, будет иметь серьезные последствия в будущем. Хрен что поменяешь и поправишь. Поэтому на проектирование API нужно уделять внимание. А для этого нужно немного прокачаться, например, в том как делать REST API, знать про открытые и закрытые схемы, про принципы формирования ответов, обработки ошибок и всего такого (а они там есть). Это не хухры мухры, когда речь идет про проектирование каких-то сложных действий, авторизаций и других механизмов.
Отложенные решения
Хорошая архитектура не в том, чтобы заранее все продумать, а в том, чтобы отложить принятие решений до момента, когда у нас есть достаточно информации. Плохие архитектуры чаще всего страдают от преждевременных оптимизаций: усложнили, чтобы “на будущее”, а это будущее не наступило.
- Все, что можно поменять без боли - оставляем простым.- Все, что будет трудно поменять (API, модели, схемы БД, протоколы взаимодействия) - продумываем особенно тщательно.
Retrofit — это библиотека, которая стала стандартом для работы с REST API в Android-приложениях. В нашей статье «Погружаемся в недра Retrofit» мы подробно разбираем, как использовать Retrofit максимально эффективно, чтобы упростить код и повысить стабильность приложений.
Обзор основных возможностей Retrofit: от простой отправки запросов до работы с асинхронностью и обработкой ошибок.
Интеграция с OkHttp — что дает и как использовать на полную мощность.
Механизмы конвертации данных: Gson, Moshi и как кастомизировать парсинг.
Реальные примеры кода, которые можно сразу применять в своих проектах.
Советы по тестированию Retrofit-клиентов и особенностям работы с сетевыми вызовами.
Для кого статья? Для Android-разработчиков всех уровней, которые хотят улучшить качество сетевого кода и сделать его более поддерживаемым. Для тех, кто только пробует Retrofit и тех, кто хочет расширить свои знания и узнать внутренние тонкости работы этой библиотеки.
Ускоряем релизы и улучшаем качество с помощью Unleash
Сейчас в Альфа-Банке мы рассматриваем возможность внедрения фича-тоглов в наш проект и проводим исследование уже существующих решений. В рамках него мне удалось глубоко познакомиться с Unleash — самой популярной платформой для фича-тоглов на данный момент.
В статье «Разбираемся с Feature Toggle на примере Unleash» подробно объясняем ключевые понятия и возможности Unleash — от определения тоглов до сложных стратегий и сегментов. Демонстрируем реальные примеры кода и архитектурных подходов на Java и Spring и рассказываем о практических плюсах Unleash
Статья будет полезна Backend-разработчикам и тимлидам, DevOps и SRE-инженерам, менеджерам продуктов и качества и всем, кто планирует масштабировать систему с десятками и сотнями микросервисов, где требуется централизованный и удобный контроль остаточного риска внедрения новых функций.
Платформенная команда: секретный инструмент для масштабирования бизнеса
В ЮMoney мы используем стандартный фронтенд-стек — React, TS, Nest.JS — и микросервисную архитектуру с более чем 70-ю сервисами. По мере роста компании, количества команд и сотрудников в отделе нам понадобились единые стандарты в разработке и общий вектор развития. Эти потребности теперь закрывает платформенная команда.
Главная задача платформенной команды — создать фундамент для всей остальной разработки.
Преимущества такого подхода заключаются в том, что появилась единая стратегия технического развития всего отдела, больше возможностей для экономии ресурсов, стандартизации и контроля качества. Кроме того, этот подход способствует эффективному внедрению новых технологий во всех продуктах.
Платформенные команды эффективны, если перед вами стоит вопрос масштабирования технологий внутри компании. Такая команда снижает расходы на разработку, упрощает подбор сотрудников и помогает реализовывать техническую стратегию. Однако такой подход не для всех — он требует определённых масштабов и определённого уровня зрелости организации.
Подробнее о подходе, задачах команды и преодоленных трудностях — в статье на Хабре.
Лайфхак для начинающих разработчиков: уделите время изучению Английского
Да, да, учить не язык программирования, а нативный язык, сначала, или параллельно.
Это нужно чтобы получить преимущество на страте и забрать +100 к пониманию кода, документации, книг, статей и видосов по разработке. (И того что дают на выходе вайбкод-инструменты тоже.)
Очень многое завязано на английский в IT-мире, и названия железок, технологий и абстракций взялись не из воздуха, а как отсылки-аналогии на другие реальные объекты.
Например Server - это не только привычный нам сервер, а еще и официант. А Client - это клиент заведения. А заведение предоставляет Service.
Те же языки программирования например придумали англоговорящие люди, чтобы писать инструкции машинам на языке близком к английскому. (Понятно что сейчас можно вайбкодить на родном языке, при этом в мире IT по прежнему терминология завязана на English и в нашем тоже много англицизмов к которым мы просто привыкли.)
Еще, как бонус, говорят что это и для памяти и для здоровья ума полезно, так как изучение языков развивает и поддерживает когнитивную функцию. (Это уже не для начинающих, а для продолжающих скорее лайфхак 😁 )
Для того чтобы прокачаться в инглише много не надо. Банально можно поставить себе Duolingo и играться с ним по 10-15 минут каждый день. И этот простой шаг поможет не только изучению английского, но и программированию.
Я написал простой рассказ чтобы наглядно показать то что я имею ввиду, это может помочь, хотя конечно больше от вас зависит:
Let's start!
Sveta and Maxim walk in the city center.
"I'm hungry and want to eat," said Sveta. "See, there's a cafe nearby; this cafe provides good service," said Maxim.
Maxim is a regular client of this cafe, and he likes its service. They enter the cafe.
"Hi, Maxim," said the server Maria. "Hi, Maria, menu please," said the client Maxim.
The server Maria gives them the menus.
Client Maxim orders a cake and tea. Server Maria receives the order. Client Sveta orders a hamburger and coffee. Server Maria receives the order.
Then, server Maria passes the order to the cook Leonid. Then, Leonid prepares the food for the clients. After a while, server Maria passes the tea and cake to client Maxim. And then, server Maria passes the coffee and hamburger to client Sveta.
Next, client Sveta eats her hamburger, and client Maxim eats his cake.
"I'm so happy, dear," said Sveta. "I'm happy too, honey," said Maxim.
"Thank you for the good service, Maria," said client Maxim. "You are welcome, Maxim," said server Maria.
The End :)
Делитесь своими мыслями и опытом в комментариях, хорошего вечера :)
P.S. Ну и сводите кого-нибудь в кафе на свидание, чтобы прочувствовать атмосферу метафоры, так лучше запоминается 😊
P.P.S. Проверка на внимательность: как зовут спутницу Максима, Света или Мария?
Zhipu AI выпустила GLM-4.6 с контекстом 200K токенов и производительностью уровня Claude Sonnet 4
Китайская компания Zhipu AI (Z.ai) представила GLM-4.6 — обновленную версию флагманской модели с расширенным контекстом до 200K токенов и улучшенными способностями в программировании, рассуждениях и агентских задачах. Модель показывает паритет с Claude Sonnet 4 при снижении потребления токенов на 15%.
Технические улучшения
GLM-4.6 построена на архитектуре предшественника GLM-4.5 с существенными оптимизациями обработки длинного контекста и генерации кода. Модель тестировалась на восьми публичных бенчмарках, покрывающих агентов, рассуждения и программирование.
Ключевые характеристики:
Контекст расширен со 128K до 200K токенов
Улучшенная генерация фронтенд-кода
Многошаговые рассуждения с использованием инструментов
Интеграция в поисковые и инструментальные фреймворки
Снижение потребления токенов на 15% относительно GLM-4.5
Результаты бенчмарков
На LiveCodeBench v6 модель набрала 82.8 балла против 63.3 у GLM-4.5 — существенный прирост. Claude Sonnet 4 лидирует с 84.5, но разрыв минимальный. На SWE-bench Verified GLM-4.6 показала 68.0 против 64.2 у предшественника.
Производительность в бенчмарках:
LiveCodeBench v6: 82.8 (GLM-4.5: 63.3, Claude Sonnet 4: 84.5)
SWE-bench Verified: 68.0 (GLM-4.5: 64.2)
CC-Bench: 48.6% win rate против Claude Sonnet 4
Снижение токенов: 15% относительно GLM-4.5
Компания расширила CC-Bench более сложными задачами, где человеческие оценщики работали с моделями в изолированных Docker-контейнерах, выполняя многошаговые реальные задачи от фронтенд-разработки до анализа данных.
Практическое применение
GLM-4.6 интегрирована в популярные агенты кодирования: Claude Code, Kilo Code, Roo Code, Cline. Модель доступна через Z.ai API platform и OpenRouter для разработчиков.
Для программирования:
Генерация фронтенд-компонентов с логичной структурой
Создание инструментов и автоматизация
Анализ данных и тестирование
Алгоритмические задачи
Ценообразование и доступность
GLM Coding Plan предлагает производительность уровня Claude по цене в 7 раз ниже с троекратной квотой использования. Модель доступна через веб-интерфейс chat.z.ai и API.
GLM-4.6 показывает конкурентоспособность с DeepSeek-V3.2-Exp и Claude Sonnet 4, но отстает от Claude Sonnet 4.5 в программировании. Модель опережает китайские аналоги при использовании на 30% меньше токенов.
Конкурентная позиция:
Паритет с Claude Sonnet 4 в реальных задачах
Превосходство над китайскими альтернативами
Отставание от Claude Sonnet 4.5 в кодинге
Токен-эффективность выше на 15-30%
Архитектура и развертывание
Модель поддерживает современные фреймворки инференса для эффективного локального развертывания. Доступны базовая и чат-версии для различных сценариев использования.
Всесторонние инструкции по развертыванию опубликованы в официальном GitHub-репозитории с примерами интеграции и конфигурации.
Оценка реального использования
Компания подчеркивает, что реальный опыт важнее лидербордов. Траектории выполнения задач из CC-Bench опубликованы на HuggingFace для исследований сообщества, обеспечивая прозрачность оценки.
Если материал был полезен, поставьте, пожалуйста, плюс — мы стараемся выбирать для вас только самые актуальные и интересные новости из мира ИИ.
Разбираю статью про обучение с подкрплением для самых маленьких и генерацию ответов
Все мы знаем, что большие модели любят учиться на готовых ответах. Но, угадай что? Готовых ответов у нас нет. Они либо дорогие, либо спорные, либо вообще непонятно какие. Представь, что у тебя есть только ты сам, твои черновики и пара свободных вечеров. Ну что, будем учиться на своих же косяках?
Вот для этого придумали Compute as Teacher (CaT). Работает оно так:
Модель честно пишет сразу несколько версий ответа. Каждая по-своему кривая, но иногда попадаются удачные куски.
Другая копия этой же модели собирает из них «лучший хит» — вроде плейлиста «самое ок» из твоих старых песен.
Потом мы сравниваем все черновики с этим «финальным шедевром» и решаем: «ага, вот это было ближе, а это лучше забыть как страшный сон».
Модель сама делает выводы и в следующий раз уже тупит чуть меньше.
В итоге получается странная штука: модель учится без учителя, проверяя сама себя. Как если бы школьник писал 5 вариантов решения задачи, потом сам делал «сборку Франкенштейна» из них, и именно её принимал за эталон. А дальше наказывает себя за плохие черновики и хвалит за удачные.
И что самое весёлое — это реально работает. Без людей, без правильных ответов, без пафоса. Просто куча вычислений, которые модель тратит на то, чтобы спорить сама с собой и становиться чуть умнее.
Если коротко: CaT — это как спорить с самим собой в душе, только полезно
Ссылка на статью у меня в блоге, потому что у меня карма маленькая и тут я не могу всё опубликовать
Всего один час — и вы тратите на облако меньше 💸☁️
Облачная инфраструктура растет, расходы тоже, а следить за ними становится все сложнее... Мы вас понимаем — и зовем на вебинар, где расскажем, как сэкономить без сокращения ресурсов и мощностей.
О чем поговорим на встрече:
Покажем реальные кейсы, как управлять расходами в личном кабинете Cloud.ru.
Как перестать считать траты вручную — и начать автоматически.
Как настроить уведомления и лимиты, чтобы быстро реагировать на превышения.
Расскажем, как найти неэффективные ресурсы и сократить их использование.
Как настроить подробную аналитику, тестирование и фильтры.
Как сэкономить еще больше, если использовать бесплатные возможности Evolution free tier 😉
📅 Когда? 7 октября в 11 по мск.
📍Где? Онлайн. Регистрируйтесь на вебинар по ссылке →
А пока ждем встречи, спросите у AI-помощника Клаудии, как оптимизировать ресурсы в вашем облаке — найти Клаудию можно в личном кабинете Cloud.ru.
Нам нужно сделать что-то вроде IT-профсоюза чтобы защитить людей от произвола работодателей, нанимателей и продавцов курсов.
Так как дело обстоит сейчас - никуда не годится.
IT-специалистов за людей не считают, независимо от стажа и ранга, будь ты junior, middle, senior или teamlead, ты сталкиваешься с проблемами при трудоустройстве.
Понятное дело что мы уже попривыкли к такому обращению, но разве нас это устраивает?
Меня - нет.
Причем страдаем не только мы - трудяги, но и сами наниматели и работодатели, потому что все мы в одной лодке.
Сейчас на рынке труда разработчики грызутся между собой за кость щедро брошенную со стола "хозяина". Ситуация напоминает описанную в теории игр "Дилемму заключенных"(там где про равновесие Нэша), когда напарники действуют друг-другу и себе в минус, и выигрывает всегда 3-я сторона, из-за того что напарники не имеют возможности общаться друг с другом.
Но мы то не заключенные, мы то слава богу свободные!
И у нас есть возможность общаться друг с другом и договариваться для получения обоюдовыгодных результатов.
Я сам технарь и пару десятков лет прожил как интроверт, замкнутым сам в себе, одиночка. Не надо так.
Мы можем общаться и достигать совместных успехов, защититься от произвола нанимателей и перестроить этот рынок труда. Тем более сейчас, когда он на пике своей несостоятельности.
P.S. если такое объединение уже есть - дайте ссылку, я впишусь P.P.S не знаю что точно надо делать, но решил что буду что-то делать, телеграм канал лишнее таких уже куча а воз и ныне там, очевидно чего-то не хватает, пока можно обсуждать здесь
Авторы из AI Institute, University of Montreal, Princeton University. Статья внушает доверие. Она также подтверждается моими собственными наблюдениями
Ребята говорят о экономии токенов на модельках, 46% меньше потребление ресурса + как следствие ускорение
Суть в том, что модели много рассуждают об известных фактах. Например, если модель попросить решить уравнение с геометрической прогрессией. Она сначала его выведет, а потом будет решать. И так шагов может быть много. У больших моделей есть привычка «думать вслух». Они, когда решают задачу, раскладывают всё по шагам — иногда очень длинно. Это классно для качества, но плохо для скорости и денег: чем больше токенов, тем дороже и медленнее
Пример на прогрессии
Ты просишь модель: «реши уравнение с геометрической прогрессией»
Что она делает?
Сначала начинает выводить саму формулу суммы прогрессии: пишет длинное рассуждение, как она получается.
Потом подставляет числа.
Потом делает вычисления.
И только в конце даёт ответ.
Каждый раз она повторяет эту историю, как будто «заново изобретает велосипед».
Что предлагают авторы статьи
Ребята говорят: зачем каждый раз заново выводить одно и то же? Давайте выделим такие повторяющиеся шаги в маленькие «карточки-подсказки» (они называют их behaviors).
Например, поведение: «Сумма первых n членов геометрической прогрессии = (a₁(1–qⁿ)) / (1–q)».
Теперь, когда модель решает задачу, мы ей сразу даём эту карточку. Она не тратит сотни слов на то, чтобы вывести формулу, а сразу использует её.
Почему это полезно
Экономия ресурсов: в экспериментах до 46% меньше токенов.
Ускорение: модель тратит меньше времени на текст.
Качество не падает, а иногда даже лучше — потому что меньше места для ошибок.
Итог
Классика: модель сама думает длинно, это дорого и долго.
Новый подход: мы даём ей готовые «кирпичики рассуждений» (behaviors), она использует их и отвечает быстрее.
В общем виде: решение = текст задачи + набор подсказок.
Тут можно формулы привести со всякими условными вероятностями. Душнить не буду. И так надо форточку открывать
Приглашаем на вебинар, посвященный вопросам перехода на отечественную Java-среду исполнения. Обсудим, как указы №166 и №250 и приказ Минцифры №21 задали курс на импортозамещение и определили классы ПО для замены.
Поговорим о рисках зарубежных решений, требованиях к безопасности и роли среды исполнения как ключевого слоя ИТ-систем
Кому будет полезен вебинар: • Директорам по информационной безопасности • Техническим директорам • Директорам по ИТ • Руководителям отдела программного обеспечения • Разработчикам информационных систем
Вебинар проведет: Роман Карпов, Директор по стратегии и развитию технологий Axiom JDK, Руководитель ИБ-комитета АРПП "Отечественный софт", Руководитель технического комитета АНО "Открытый код", Советник Министра цифрового развития по вопросам системного ПО, председатель ЦКР по управлению ИТ-инфраструктурой
Всех приветствую! Видел ТГ бота который присылает аварии(инциденты, ДТП) сразу как то их создали на яндекс картах в определенных городах! Попытался сделать такого же, опыт в разработке ботов имеется, но увы я ни как не могу достать из яндекса инфо о ДТП, перерыл все их АПИ, отрисовать на карте слой с ДТП могу, а вот получить данные для обработки ни как вообще! Может кто знает какой то секрет? Буду благодарен любой помощи!
RCS (Rich Communication Services) — это эволюция SMS/MMS, протокол, который мобильные операторы и Google продвигают как «мессенджер по умолчанию». Если SMS = plain text, то RCS = полноценные интерактивные сообщения с кнопками, каруселями, картинками, видео, QR-кодами и встроенной аналитикой.
Ключевые моменты
Протокол: работает поверх IP, а не через старую SMS-сеть, но доставляется в «стоковое» приложение сообщений (Google Messages, Samsung Messages).
API: доступ через Google Jibe Hub (фактически, центр маршрутизации), плюс нужно согласование с операторами. Прямо в код «в лоб» не залезешь — всё через провайдеров/агрегаторов.
Безопасность и доверие: каждая компания-отправитель проходит верификацию бренда, чтобы на экране у пользователя сообщения выглядели не как «спам», а с логотипом и цветами бренда.
UX: разработчик не отправляет просто текст, а собирает карточку или интерактив через шаблон/SDK → пользователю приходит сообщение, похожее на push или мини-приложение внутри SMS.
То есть RCS = «SMS на стероидах», но с кучей бизнес- и бюрократических ограничений. Главная боль — доступ к API и вся регуляторка, поэтому на рынок вышли «коробочные» сервисы (как Smobi), которые берут эти сложности на себя
Чем дольше живу, тем сильнее поражаюсь способности людей «заплетать» свои собственные мозги. И, кажется, программисты в этой области вне конкуренции. Уже писал некоторое время назад, как я завел цикл внутри цикла с тем же именем счетчика. Это было пару часов отчаяния, сопровождавшегося размышлениями о том, что фундаментальные законы мира внезапно изменились, а меня забыли поставить об этом в известность. Недавно я повторил этот трюк, правда с некоторыми занятными модификациями. Был у меня в проге цикл по объектам в списке. Там смысл в том, что при некотором условии новый объект добавлялся в конец этого самого списка. Все бы ничего, но в этот момент счетчик объектов инкрементировался. А он то как раз и служил верхней границей цикла… В общем, как легко понять, дело кончилось segmentation fault… Но эту бажину (хотя она даже более заморочная на мой вкус) , я нашел относительно быстро, не успев погрузиться в бездну отчаяния. Кода было немного, поэтому обошлось без смен компилятора и переустановок IDE… В этот раз, можно сказать, повезло. И бездна отчаяния меня миновала. Но тот, кто ищет проблем, обязательно их находит. И что самое удивительное, что я их нахожу всегда в одном месте. Я в-общем то хорошо знаю, что люди еще не придумали ничего хуже конечных автоматов (state machines). И вот уже 35 лет регулярно наступаю на одни и те же грабли… В этот раз мне всего-навсего нужен был один флаг. В задаче Винтика и Шпунтика используется нетривиальный алгоритм, многократно использующий рекурсию. Ну и мне нужен был этот флаг, как индикатор того, что некое событие произошло. А когда происходило другое событие, этот флаг сбрасывался. Стандартная, в-общем, ситуация, но внутренний голос немедленно поднял «красный флаг опасности» и зашептал в голове «Нахлебаешься, Валер, ой, нахлебаешься...» И вот тут бы мне остановиться и подумать, но я, как обычно, решил, что сейчас сделаю, а подумаю потом… Все дело в том, что эти флажки (или состояния конечного автомата) имеют дурное свойство размножаться, куда быстрее чем кролики. За первым флажком немедленно последовал второй — ну просто для того, чтобы обозначить функцию, которая первый флаг установила. А потом третий, чтобы обозначить функцию, которая его сбросила… И мне уже казалось, что вот они разверзающиеся врата ада, но, конечно же, это было еще не так. Ибо настоящий ад наступил, когда программа стала многопоточной. И это еще при том, что у меня есть хорошая привычка обкладывать модификацию всех этих флажков критическими секциями. Даже если не надо. Всегда легче потом убрать и удивиться тому, что все работает, чем сутками докапываться, почему нет. Это уберегло меня от многих проблем, но не уберегло от главной. Сейчас этих флажков в программе 12. И они живут своей собственной жизнью. Я уже не в состоянии отследить кто, где, когда и зачем их модифицирует. Начал думать о том, что надо бы ввести для каждого флажка некую структуру, которая будет содержать ответы на эти вопросы. Но тут уже внутренний голос встал на дыбы, и, как ни странно, в этот раз я его послушал. Вот сижу теперь и думаю над романом (или длинным рассказом) о программисте, который взялся за непосильной сложности алгоритм и постепенно сходит с ума. Хуже того, что он это сам понимает, и ему становится страшно. Но поскольку он программист, то свой мозг он считает конечным автоматом, и пытается его «отлаживать». Таким образом запускается бесконечная цепь рекурсий. И периодически ему приходит в голову мысль, что надо все бросить и написать заново. Но он боится потому что давно уже потерялся и не знает на каком уровне рекурсии он находится… Такой вот юмористический (а может и не юмористический) хоррор с элементами мистики. И легким флером безнадеги из набоковской «Защиты Лужина». Ну вот. Написал пост. Немного отвлекся. Пойду дальше код дебажить…😁
Помогает ли олимпиадное программирование в реальной разработке
Этот и ещё пять тезисов об олимпиадном опыте разобрали с бывшим олимпиадником, Антоном Чаплыгиным, и неолимпиадником, Мишей Усковым. Оба — ведущие инженеры-программисты в Контуре.
В тусовке олимпиадников существует определённая культура превосходства и часто эти ребята воспринимают неолимпиадников как менее квалифицированных программистов
Неолимпиадник: Да. Я ощутил это, когда учился на первых двух курсах универа: перед сессией ребята-олимпиадники говорили, что даже не будут готовиться к экзамену, потому что и так всё знают. 👌 Потом они, конечно, всё заваливали, шли на пересдачу, но гонора до этого момента было много. =) Со временем такие ребята стали проще.
Олимпиадник: Подтверждаю! Например, я пришёл в универ из регионального лицея и у меня были проблемы с неалгоритмическими предметами, например, матанализом. Те, кто уже учил его, считали, что они-то всё знают, а я — нет.
В олимпиадной среде есть соревновательный дух, на нём всё держится. Но считаю, когда попадаешь на учёбу, лучше этот гонор отложить в сторону и с людьми начать нормально общаться.
Олимпиадное программирование бесполезно в реальной разработке. 99% задач в индустрии не требуют сложных алгоритмов
Олимпиадник: Согласен с тезисом, что большая часть задач не требует каких-то алгоритмических подходов, особенно в продуктовых командах. В инфраструктуре этого обычно больше, и когда я сталкиваюсь с алгоритмами, кайфую от этого.
Неолимпиадник: Согласен, что в продуктах алгоритмических задач мало, но они часто критичные. Ты можешь делать 900 простых задач, но без сложных вообще никуда не уедешь. В Контуре есть своя база данных, своя очередь. Мы можем сделать в сервисе много красивых финтифлюшек, но если у нас не будет быстро работать база, мы никому не будем нужны.
Вот ты пользуешься какими-нибудь библиотеками, фреймворками, но при этом не знаешь, что происходит внутри, — это не прикольно. А олимпиадные задачи часто про структуры данных, про Computer Science, и это всё хорошо бы знать.
При этом я считаю, что где-нибудь в промышленной разработке лучший олимпиадник — далеко не всегда лучший программист. Ведь программист — это не только про «У меня есть задача, я превратил её в код», а скорее про «Я знаю, с кем поговорить, что уточнить».
Олимпиадников сложно переучить, они склонны оптимизировать несущественные вещи
Неолимпиадник: У нас в команде были олимпиадники, и когда они брались за задачи, было видно, что им интересно их «покопать», сделать из этого красивое решение, чтобы оно идеально работало. Это всё хорошо, но не всегда такое надо, особенно когда хочется уже быстрее получить результат. =) В этот момент приходилось немного поторопить человека. А потом подсластить ему пилюлю: например, дать прикольную задачу с Computer Science.
Олимпиадник: Считаю, что скорее всё зависит от человека. Бывают люди, которых в принципе трудно переучивать, а бывают те, которым можно объяснить один раз, и они всё поймут. Хорошо, что есть курсы и книжки по чистому коду, в которых ты можешь чему-то научиться и понять, как это применять. Так же, как ты научился писать алгоритмы когда-то.
Алгоритмические задачи на собеседованиях не всегда показывают реальные навыки разработчика
Олимпиадник: Люди во время собеса часто нервничают, из-за этого забывают какие-то элементарные вещи. Но потом, когда приводишь человека в чувство, успокаиваешь, становится понятно, что он всё знает, просто запаниковал тогда и из-за стресса наделал ошибок.
Неолимпиадник: Согласен с этим тезисом, потому что, во-первых человек может запаниковать, во-вторых — ему может попасться задача, с которой он ещё ни разу не сталкивался. Но он точно смог бы решить в спокойной обстановке, когда под рукой поисковик или нейронка. Поэтому считаю, что «валить» кандидата алгоритмами на собеседовании — не самый лучший способ проверить уровень его знаний.
Немного лекций с нашего митапа питонистов в Новосибирске - PythoNSK (https://t.me/python_in_nsk приходите, в ноябре планируем вторую встречу организовать).
