#Education

Кристаллы на процессоре

Когда смотришь на новенький Ryzen или Core i9, видишь лишь металлическую крышку и логотип. Но под ней, в самом сердце, лежит не просто «камень», там искусственно выращенная вселенная, самый совершенный кристалл на планете. И от его качества зависит будет ли твой процессор летать или едва ползти.

Что это вообще такое — «кристалл»?

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

Что на нём «делают»?

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

Транзисторы это здания. Каждое по-сути микроскопический переключатель, который либо пропускает ток (1), либо нет (0). Современный 3нм техпроцесс это когда «здание» настолько мало, что для его постройки используют пучки единичных атомов.

Слои металлизации это дороги и электросети. Транзисторы нужно соединить в схемы. Над кремнием создают до 15-20 слоёв микроскопических «проводов» из меди или кобальта. Это многоуровневая развязка, где каждый «проспект» и «переулок» подведён к нужному «зданию»-транзистору. Чем совершеннее процесс, тем тоньше и плотнее эти дороги, соответственно меньше задержки, выше скорости.

Кэш это сверхбыстрые склады прямо в городе. Чтобы процессор не бегал за каждой инструкцией в медленную оперативную память, прямо на кристалле встраивают сверхбыструю статическую память (SRAM). L1, L2, L3 кэш это как полки, холодильник и кладовая прямо на кухне, чтобы не ходить в магазин через дорогу каждый раз.

Почему это так сложно?

Чистота. Одна пылинка, попавшая на пластину во время производства, убьёт десятки тысяч транзисторов. Заводы чище, чем операционная, а воздух фильтруется до класса 1 (менее 1 частицы на куб. фут).

Точность. Линии на кристалле сегодня тоньше длины волны видимого света. Чтобы их нарисовать, используют хитрости вроде EUV-литографии — «печатают» лазером, бьющим по каплям олова, чтобы создать плазму с излучением в 13.5 нм. Это одна из самых сложных машин, созданных человечеством.

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

А зачем там несколько кристаллов?

Раньше один процессор был одним большим кристаллом, но делать огромные, идеальные кристаллы дорого: один дефект и весь чип в утиль. Теперь используют чиплеты: несколько маленьких, идеально сделанных кристаллов помещают на одну общую подложку (интерпозер), и они общаются друг с другом по сверхбыстрой шине. Это как вместо одного огромного завода построить промышленный парк из нескольких цехов, связанных скоростными конвейерами. Дешевле, гибче, выше выход годных.

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

#Programming #Kotlin #Dart #KMP #Flutter

KMP vs Flutter

Если вы думаете что это выбор между двумя фреймворками, вы ошибаетесь. Это два лагеря, два видения мира, где каждый искренне убеждён, что оппоненты недалёкие анунаки, не понимающие очевидных вещей.
Посадите в одну комнату Senior Android-разработчика, который три года пилит KMP и Flutter-энтузиаста, который с нуля сделал пять приложений. Они не договорятся и в лучшем случае порвут друг друга в клочья.

Основная философия

Лагерь Flutter: «Ребята, какой нативный UI? Мы живём в 2026 году, у нас везде одни и те же дизайн-системы Material и Cupertino, которые пользователи уже давно не отличают от родных. Наша миссия убить дублирование кода насовсем: одна кодобаза, один язык, одна команда и приложение на iOS, Android, Web и даже на десктопе как с конвейера. Мы строим кроссплатформенный монолит и это прекрасно, а вы с вашими танцами с бубнами, вокруг двух кодобаз, просто застряли в 2010-х».

Лагерь KMP: «Вы, флаттеровцы, как дети которые радуются фломастеру, рисуя поверх шедевра. Ваша философия это вандализм, ведь вы берёте сложнейшие, отточенные годами платформенные UI-киты UIKit, Jetpack Compose и просто заменяете их своим самопальным рендерером на Skia. Да, он быстрый, но он чужой. Наш путь это путь архитектурной чистоты, потому что мы не трогаем святое — UI. Мы берём то, что действительно должно быть общим: логику, бизнес-правила, состояние, данные. Пишем это один раз на Kotlin и встраиваем в нативные приложения, которые пользователи ожидают получить. Мы не строим стену между юзером и его телефоном, Мы творим проход между разумными командами».

Язык и экосистема

Flutter-отряд: «Вы хотите заставить моих iOS-разработчиков, которые 10 лет дышали Swift и Xcode, учить Kotlin? Это бред, а Dart это современный, строгий, предсказуемый язык. У него потрясающий тулинг: hot reload, который реально работает, а не та унылая поделка что у вас. Вся экосистема заточена под фронтенд. Pub.dev это рай где на любой случай жизни есть три пакета. Ваш expect/actual это костыль уровня #ifdef из 90-х за который должно быть стыдно».

KMP-защитники: «Дарт? Серьёзно? Язык-зомби, который оживили только чтобы толкать Flutter? Его нигде кроме как у вас не используют. А Kotlin это стандарт для Android, язык для бэкенда (Ktor) и соответственно Multiplatform. Мои разработчики уже знают его и могут взять существующую тонну бизнес-логики из нашего бэкенда или Android-приложения, и засунуть её в iOS почти без изменений. Мои iOS-ребята учат не Kotlin, а архитектуру. Они получают готовые, протестированные модули и просто рисуют под них вьюхи. А ваша экосистема это свалка из тысячи пакетов, половина из которых заброшена потому что каждый школьник, сделав виджет-кнопку, выкладывает её на pub.dev».

Разработка кода

Flutter-инженер, тыкая пальцем в экран: «Смотри: вот у меня список, мне нужно добавить сложную pull-to-refresh анимацию с параллаксом, кастомным индикатором и изменением цвета. В Flutter это 30 минут работы. Один пакет, или даже самописный CustomScrollView. А теперь расскажи, как ты это будешь делать в KMP? Ах да, сначала ты три дня будешь писать общий expect-класс с данными, потом твой Android-разработчик неделю будет имплементировать это на Compose, а еще позже iOS-разработчик две недели будет втыкать в документацию SwiftUI, проклиная всё на свете, потому что анимации там другие. И в конце вы получите два разных поведения и втрое больше кода. Гениально».

KMP-архитектор, хладнокровно поправляя очки: «Ты описал не проблему, а её решение. Да, UI должен быть разным на разных платформах, потому что UX на iOS и Android разный. И да, мы платим за эту гибкость сложностью координации, но теперь опиши мою задачу: у меня есть сложный модуль расчёта кредитов с десятком правил, интеграцией с банковским API и кэшированием. В Flutter ты будешь писать его на Dart и молиться, чтобы пакет для работы с gRPC был стабильным, а на iOS не отваливалась сборка из-за какой-нибудь проблемы с Carthage. А я возьму проверенную, юнит-тестированную годами библиотеку на Kotlin, которая уже работает на бэкенде.

...оберну её в KMP-модуль и она заработает на обоих платформах идентично и без сюрпризов. Ваша «простота» иллюзорна. Она работает, пока ты в песочнице. Когда приходит реальный, сложный бизнес вы начинаете городить Platform Channels, что по сути есть признание поражения вашей «универсальности»».

Кто ты по масти?

Вы Flutter-boy если:

Вам критически важна бешеная производительность и нативное ощущение (интерактивные карты, сложный скролл 60fps).

У вас уже есть большие нативные команды, которые не хотят и не будут учить Dart.

Ваше приложение — это по сути нативный системный компонент, глубоко интегрированный в ОС.

Вы Kotlin-org если:

У вас стартап из трёх человек, которым нужно за месяц выкатить MVP на все платформы.

Ваше приложение это простой CRUD с формочками, где бизнес-логики на 50 строк.

Вам плевать на нативный UX, вам нужен один дизайн везде, и вы готовы за него бороться.

В мире не бывает серебряной пули. Flutter это феноменальная скорость и единство на начальном и среднем уровне сложности. KMP это стратегическая точность и контроль для сложных, долгоживущих проектов с устоявшимися командами. Один лагерь кричит: «Смотрите, какой у меня красивый единый интерфейс!». Другой парирует: «А мой интерфейс — родной для пользователя и логика у меня выверена алмазом».

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

#Programming #Kotlin #Dart #KMP #Flutter

#Programming #Python

Flask позволяет быстро создавать сайты, оказывается

Бывает такое: месяцами работаешь с монструозными enterprise-фреймворками, где нужно 10 конфигов, 5 скриптов инициализации и ритуал с бубном, чтобы поднять Hello, World. Ты погружён в инъекции зависимостей, слои абстракций и философию «сначала архитектура, потом код» и кажется что иначе нельзя. А потом случайно открываешь Flask и понимаешь что всё это время тебя просто водили за нос.

Моё откровение было простым до смешного: Хотел наскоро сделать сайт с размером в 10 эндпоинтов, логикой на 500 строк, обработкой файлов и отдать JSON. По привычке полез настраивать Laravel и нырять в дебри PHP, но я вспомнил про python и подумал: «А почему бы во второй раз не попробовать»? (До этого был печальный опыт с ним)

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

Вот весь код приложения, которое уже можно запустить и оно ответит по HTTP:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello():
    return {'message': 'Hello, World!'}

if __name__ == '__main__':
    app.run(debug=True)

И это не игрушка, а рабочий инструмент без настройки миллиарда конфигов, никаких обязательных папок controllers/, services/, repositories/. Никакого кодогенератора, который создаёт 20 файлов, просто пишешь функцию и говоришь: «Эй, эта функция будет отвечать на запросы по этому адресу».

В чём фокус? Flask это микрофреймворк, его философия заключается в том чтобы дать самый минимум для старта, а всё остальное ты добавишь сам если нужно. Необходима работа с базой? Ставишь Flask-SQLAlchemy. Нужна аутентификация? Flask-Login. Нужны миграции? Flask-Migrate. Но если не нужно — не ставишь, никто не заставляет тебя тащить за собой килограммы зависимостей «на всякий случай».

Конечно, у этого подхода есть обратная сторона. Для большого проекта с командой из 10 человек можно наворотить таких костылей,что потом будет больно поддерживать. Flask не диктует архитектуру, он даёт свободу, а свобода это ответственность. Можно написать монстра на 5000 строк в одном файле, и Flask это проглотит и это будет твой выбор, и твоя проблема.

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

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

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

1. Stud-Informer
2. irkpo-events

Оба проекта будут закрыты на неопределённый срок. Общий доступ (open source) сменится на проприетарную лицензию из-за невозможности продажи.

#DevOPS

Deploy проекта

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

Пора заканчивать с этим средневековьем. Deploy pipeline (пайплайн развертывания) это ваша автоматическая линия по сборке, проверке и доставке кода из гита на сервер. Это когда вы просто пушите в ветку, а дальше работает бездушная машина, которая делает всё за вас и вы не можете её отвлечь или заставить забыть шаг.

Зачем это нужно?

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

2. Скорость. Автоматика делает всё быстрее и без твоих кофе-брейков.

3. Откат. Если после деплоя всё пошло по пизде, то одна команда откатит тебе приложение на предыдущую и стабильную версию.

4. Доверие. Ты знаешь что каждый коммит, который прошёл через пайплайн, был собран, протестирован и развёрнут одинаково.

Из чего состоит типичный пайплайн

1. Сборка (Build): твой код превращается в артефакт благодаря npm run build, docker build, mvn package. Если не собирается значит дальше не идём.

2. Тестирование (Test): запускаются автоматические тесты из юнитов, интеграционных и других. Если падают — не повезло.

3. Деплой на тестовое окружение (Deploy to Staging): артефакт летит на среду, максимально похожую на продакшен. Здесь можно провести ручное тестирование.

4. Деплой на продакшен (Deploy to Production): если всё окей, значит можно выкатывать на боевые сервера. Часто делается с ручным подтверждением (approval) или автоматически, если настроены canary-деплои/постепенное развертывание.

Инструменты: какие бывают конвейеры

Jenkins: старый, но могучий монстр. Гибкий, с кучей плагинов, но требует отдельного сервера и любви к настройке.

GitHub Actions / GitLab CI: модные, встроенные прямо в Git-платформу. Конфиг пишется в YAML-файле прямо в репозитории. Идеально для стартапов и большинства проектов.

TeamCity, CircleCI, Travis CI: другие облачные и self-hosted варианты. Выбор зависит от стека и бюджета.

Пример простейшего пайплайна на GitHub Actions для Node.js приложения

Файл .github/workflows/deploy.yml:

name: Deploy to Production

on:
  push:
    branches: [ main ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'

    - name: Install dependencies
      run: npm ci

    - name: Run tests
      run: npm test

    - name: Build project
      run: npm run build

    - name: Deploy to server via SSH
      uses: appleboy/ssh-action@master
      with:
        host: ${{ secrets.SERVER_HOST }}
        username: ${{ secrets.SERVER_USER }}
        key: ${{ secrets.SSH_PRIVATE_KEY }}
        script: |
          cd /var/www/myapp
          git pull origin main
          npm ci --only=production
          pm2 restart myapp

Что происходит: при пуше в main запускается виртуальная машина на Ubuntu, ставится Node.js, ставятся зависимости, прогоняются тесты, собирается проект и, если всё успешно, по SSH на боевой сервер отправляется команда на обновление.

Зачем всё это, если можно вручную?

Чтобы не быть заложником своего же процесса и любой разработчик в команде мог сделать деплой, не имея паролей от сервера в голове. Никому в 3 ночи не хочется гадать что сломалось, желательно иметь в логах пайплайна: «Упал на этапе тестов, потому что херня в коде».

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

Не смогли смириться с поражением? И куда вас это привело? Снова в мои пулл-реквесты, мои issues, мой код.

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

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

Но теперь я знаю что мне нужно, взять и переписать всё до последней строчки, последнего console.log забытого в продакшене, до последней магической константы $dollar = 42.

А после из тех баг-репортов, бессонных ночей создать новую систему, в которой код не оплакивает утраченные фичи, а ценит то что ему даровано. Без легаси, техдолга, «а почему здесь так?».

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

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

Спасибо.

#Mobile

Android и iOS становятся братьями-близнецами

Помните времена когда эти две операционки были из разных вселенных? Перейти с Android на iOS было культурным шоком почище эмиграции в другую страну? Когда айфоны выглядели как скруглённые квадратики со скевоморфизмом, а Android щеголял холографическими виджетами и оранжевым уродством Gingerbread?

А теперь посмотрите на них пядом. Material UI 3 от Google и Liquid Glass на iOS 26+ от Apple. Если закрыть логотипы, то не каждый специалист сходу определит где чей скриншот. Они сошлись и это не случайность.

Что общего?

1. Скругления, скругления, скругления. Забудьте про острые углы, везде плавные, жирные, "таблеткообразные" формы. Карточки, кнопки, поля ввода — всё превратилось в подушки безопасности. В Material 3 называет это "M3 shape" (система скруглений), в iOS просто "rounded corners".

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

3. Цвет из твоих обоев. Главная фишка Material UI это динамическая тема, которая вытягивает цвета из твоих обоев и раскрашивает интерфейс. iOS 26+ тоже научилась подстраивать оттенки интерфейса под фон, пусть и не так агрессивно, но вектор ясен: система перестаёт быть чужой, она мимикрирует под твой визуальный шум.

4. Минимализм до костей. Никаких лишних линий, границ между элементами. Воздух, пустота, белое/чёрное пространство, разделение происходит не рамками, а тенями и отступами. Это язык, который обе платформы выучили одновременно.

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

6. Типографика как украшение. Огромные, жирные заголовки которые сами по себе уже графический элемент. Material 3 ввел "дисплейные" крупные шрифты, iOS тоже не отстаёт. Текст теперь не читают, а сначала рассматривают.

Почему это произошло?

Победил лучший UX. Годы исследований, тонны A/B тестов, миллиарды пользователей привели к единому выводу: люди лучше понимают интерфейс который ведёт себя предсказуемо. Скруглённые углы безопаснее, размытие создаёт ощущение иерархии, крупные элементы удобнее тыкать.

Усталость от уникальности. Пользователи перестали хотеть учиться. Они хотят чтобы новое приложение или новая версия ОС работали "как у того парня". Зачем изобретать свайп назад, если Apple приучила всех что он работает от левого края? Google сдался и сделал так же, потому что это снижает когнитивную нагрузку.

Flutter и кроссплатформенность. Инструменты типа Flutter (который тоже от Google) стирают границы, дизайнеры рисуют один макет и он одинаково выглядит на обеих платформах.

Но различия остаются

Apple это по-прежнему "аккуратная, дорогая, спокойная гостиница". Всё очень чисто, выверено, без лишних эмоций.
Material 3 это "молодёжный лофт с неоновой подсветкой". Больше динамики, цвета, элементы могут "пружинить" и отскакивать.

Но в целом если вы покажете обывателю экран блокировки iOS 26 и Android 16, он пожмёт плечами: "Одинаковые же".

Мы живём в эру постиндустриального дизайна, где функции победили форму, а удобство оказалось важнее идентичности. Война интерфейсов закончилась, обе стороны подписали мирный договор, текст которого — Material 3 и Liquid Glass. И знаете, в этом мире жить стало проще. Особенно когда переходишь с одного телефона на другой и не чувствуешь себя иммигрантом без языка.

#ItLife

Забавно: вроде всё «как надо».
Есть работа, мак, деньги, навыки, люди, которым можно доверять. Дела идут, задачи закрываются, коммиты пушатся, Docker крутится.

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

Мы часто думаем: вот ещё немного подрасту, заработаю, докажу, стану «достаточным». А потом однажды понимаешь что ты уже стал, только полноты почему-то нет. Странное чувство, когда внешне всё нормально, а внутри тихо и пустовато.

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

Если у вас тоже так — вы не одни.

#ItLife #Other

Плата за то, что ты программист

Никто не говорит об этом на собесах, так как в вакансиях пишут стек, грейд и вилку. Не пишут остальное.

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

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

Дальше — голова не выключается. Едешь в маршрутке и думаешь про баг. Засыпаешь и думаешь про баг. Иногда просыпаешься в 4 утра с мыслью «стоп, а что если я там неправильно индекс поставил». Это не продуктивность и не трудолюбие а просто мозг, который не умеет отпускать незакрытые задачи. Со временем привыкаешь, почти.

Тело отдельная история: спина, шея, запястья. Глаза к вечеру как будто их весь день жарили на сковородке. Ты знаешь про осанку, про перерывы каждые 45 минут, про гимнастику для глаз. Ты всё это знаешь и всё равно не делаешь, потому что «сейчас вот только этот момент доделаю».

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

И при всём этом есть момент, ради которого всё терпишь, когда что-то наконец работает. Не «работает кое-как», а именно работает как надо. Смотришь на это несколько секунд молча. Объяснить данное ощущение невозможно — либо ты знаешь его, либо нет.

Профессия берёт своё. Зато и даёт кое-что, чего в других местах не найдёшь.

#Education

Почему быть ментором для джунов — это вынос мозга

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

Когда я только начинал, думал: «Ну чё сложного? Яж умный, всё объясню». По итогу оказалось я немного так ошибся. Менторство это отдельный вид искусства — искусства не сойти с ума и не расписаться в собственной беспомощности.

1. Бесконечные вопросы, на которые ответ — «загугли»

Пример из жизни: Джун:«А почему у меня докер не устанавливается?» Я(посмотрев вопрос поподробнее): «Потому что ты забыл включить wsl2, видишь?» Джун:«А как включить?» Я:«Ну в настройках Windows». Джун:«А где это?» И вот так 10 раз подряд.Ты объясняешь элементарные вещи, которые можно было прочитать в любой статье за 5 минут. Но вместо этого джун идёт к тебе, потому что «ты же ментор, ты обязан помогать».

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

2. Документация? Не, не слышал

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

Я потратил 2 часа, объясняя джуну, как сделать механизм авторизации на сайте так как он всё время путался. Потом я сдался и просто кинул ссылку на официальный гайд. Через 20 минут он написал: «О, спасибо, я прочитал и понял!». Я тогда чуть не разбил монитор. Эти 2 часа можно было заменить одним ссылочным кликом.

3. Синдром самозванца на максималках

Когда ты ментор, ты постоянно сомневаешься: «А правильно ли я советую? А вдруг есть решение лучше? А не устарело ли это?». Особенно когда джун задаёт вопрос, на который ты сам не знаешь ответа. Или знаешь, но не уверен. Или уверен, но потом находишь баг в своём же коде.

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

4. Эмоциональные качели

Джун может неделями тупить над простой задачей. Ты объясняешь, показываешь, рисуешь схемы, а по итогу всё равно не "объясняется" и ты начинаешь беситься. Потом в какой-то момент щёлкает и он выдаёт решение, от которого ты в шоке: элегантное, красивое, рабочее, и ты такой: «Ёбаный в рот, я горжусь», а через день он снова спрашивает «а как переменную объявить?».

Это американские горки на которые ты подписался добровольно с билетом в один конец.

5. Когда джун перерастает тебя

Самое сложное — отпустить. Ты вкладываешься, тратишь нервы, время, а потом этот человек становится круче тебя или просто уходит из поля зрения. И ты вроде рад за него, но внутри грызёт: «А меня кто-нибудь так же научит?».

Но есть и кайф.

Когда ты видишь как твой подопечный спустя N-времени сам отвечает на вопросы новичков. Когда он пишет код, который не стыдно показать. Когда он приходит и говорит: «Спасибо, я столько узнал». В этот момент понимаешь, что всё было не зря.

Менторство это не про передачу знаний, а переосмысление мышления. Научить не тому, что писать, а тому, как думать и это сложно. Но если получилось — ты красавчик.

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