В универе мне говорили: «Запоминать материал наизусть - вредно. Важнее понимать, где и как искать». Тогда это звучало необычно, а сегодня становится нормой: технологии меняются быстрее, чем успеваешь выучить. Раньше, незнание конкретики считалось минусом: «нужен тот, кто уже знает». Но теперь ии-агенты читают документацию лучше и быстрее нас всех!
И фокус сместился. Сейчас важнее не помнить, а быть гибким. Иначе легко застрять в прошлом и стать «дедом» со своими «проверенными», но устаревшими приёмами.

#мысли #ии

Поражаюсь, как современные AI-чат-боты помогают удовлетворить мою тягу к знаниям здесь и сейчас! Можно спрашивать любую неведомую дичь уровня «как натянуть ужа на дирижабль». Он, конечно, скажет: «Ты совсем чокнутый, но давай представим, как бы это вообще можно было сделать!» И всё — больше нет границ тому, о чём можно размышлять и дискутировать.

Любые идеи, типа «а что если создать устройство…» — ты сможешь спокойно обсудить и получить полноценные размышления и даже примеры решений. И даже рендер, если очень хочется. Запускай стартап и вперёд. Больше никаких границ фантазии!

Ещё 5 лет назад я мог услышать только: «Уйди отсюда, мальчик, и не задавай глупых вопросов». Безграничные знания были фантастикой, а теперь — мы уже здесь!)

Всем привет! Сегодня поучаствовал в беседе с ИТ-экспертами на тему зарплат программистов в следующем году. Ребята высказали интересные предположения. Таймкоды на мои комментарии: тыц, тыц, тыц и тыц!
Можете закидывать свои предположения и мысли)

Современная "охота на ведьм"

Если ты придумал, как делать свою работу быстрее без потери качества — это не должно никого волновать. Важно не как ты сделал работу, а за что ты отвечаешь.

Последнее время всё чаще возникает ощущение, что все вокруг пытаются друг друга уличить в использовании нейросетей.
Авторов статей критикуют за длинные тире, дизайнеров — за гиперреалистичность, разработчиков — за вылизанный код, а соискатели с HR’ами соревнуются, кто быстрее задетектит, что с ним общается AI-агент, а не человек.

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

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

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

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

#мысли #ai

Стоит ли переходить из разработки в лиды?

На эту тему меня попросили поделиться мнением для статьи на Хабре. Всего было два вопроса, и в статье приведена очень короткая цитата, так как она больше про общий сборник советов и список курсов. Но тут я приведу ответы полностью.

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

2. Как понять, что быть тимлидом — твоё? А когда стоит уходить в экспертизу, а не в менеджмент?
Начать хочется с того, что тимлид — это не следующий грейд разработчика. Это переход из технической роли в управленческую. Будет совсем по-новому, и сильные технические навыки не обязательно помогут справиться с управлением командой. В первую очередь ты перестаёшь думать за себя и начинаешь думать и нести ответственность за всю команду. Любое неверное решение другого человека становится твоей проблемой. Это, кстати, верно и в эпоху AI-агентов, когда не так важно, кто пишет код — гораздо важнее, кто несёт за него ответственность.

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

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

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

Как не деградировать, работая с нейросетями?

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

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

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

(Полная статья в блоге)

А как вы сдерживаете деградацию знаний?

Немного освежил личный сайт и блог. Сделал ещё проще! (куда уже!)
- На сайте добавил ссылки и краткую информацию обо мне, добавил тёмную тему
- В блоге поменял сборщик страниц с неповоротливого Hugo на шустрый Astro.JS + мелкие правки

Конечно, странно сейчас в 26 году вести личный сайт. Но яж могу, а значит почему бы и нет! 😛
Если найдёте ошибки - присылайте.

https://henrydev.me
https://blog.henrydev.me