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

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

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

#story #ai #book

Всем привет! На Tproger вышла моя новая статья с советами как подготовиться к смене работы.
Многие программисты выходя на рынок труда в 2025 обнаруживают: если раньше ты за пару недель мог собрать 5-10 офферов, то теперь могут даже не ответить. Я провёл небольшое исследование и собрал в одной статье основные шаги, которые помогут стать заметнее среди других кандидатов!

#post #hiring #tproger

Tproger | Блог

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

Идеальный размер команды

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

#post #teammanagment

👉 https://blog.henrydev.me/small-and-big-team/

PHP-разработчики захватили управление поездом через Wi-Fi. Поезд проехал ещё 30 секунд и остановился.

#joke #php #phpyh

Немного офтопика про онлайн-покупки в Европе.

В Евросоюзе заказывать что-то из китайских магазинов не удобно. Поэтому моим главным другом для покупок стал Amazon.

За последние пару лет я пробовал американский, британский и немецкий сайты. Сами сайты почти одинаковые, но разница чувствуется в мелочах:

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

Я на столько привык делать заказы от туда, что решился заказать что-то крупногабаритное - инверторную микроволновку с нержавеющей камерой (предыдущий опыт с Самсунгом был печальный, могу потом рассказать).

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

Но тут DHL выкатил цену за обратную доставку: €500! Я уже представил, как живу с мятой техникой, каждый раз вспоминая свой факап.

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

Моё уважение к Amazon заметно выросло! Теперь у меня есть бесплатная слегка боевая микроволновка)

В издании для рекрутеров HR Bazaar вышла моя новая статья про идеальный размер команды:
https://hrbazaar.ru/articles/komanda-iz-6-chelovek-effektivnee-20/
Прошу читать и критиковать)

Это доработанная и адаптированная статья на основе поста из блога.

Разрабы должны чувствовать последствия своих решений

Кент Бек, в своем подкасте сказал очень хорошую мысль: "Задача Ops-команды дать разработчиком прочувствовать боль своих ошибок". Немного злобная, но очень честная мысль. Девопс, как функция, должны помогать "владеть" и эксплуатировать свой код командам разработки. А никак не тащить на дев, стейдж и прод и отвечать там за поломки

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

"Практика you build it - you run it" предлагает радикально другой подход: пусть тот, кто создает проблему, сам с ней и разбирается. Не из садизма, а из понимания простой истины — только почувствовав боль, разработчик начинает писать код по-другому. Когда разработчик знает, что в 3 утра его разбудит алерт от его собственного кода, магическим образом меняется отношение к качеству:
- Логирование становится осмысленным, а не формальным
- Обработка ошибок из "авось пронесет" превращается в продуманную стратегию
- Мониторинг закладывается на этапе проектирования, а не добавляется постфактум, чтобы номинально удовлетворить требования
- Архитектурные решения перестают приниматься по модели "и так сойдет"

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

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

Хороший разработчик думает не только "как это реализовать", но и:
- Как это будет деплоиться?
- Как это будет мониториться?
- Что будет, если это упадет?
- Как быстро можно будет найти и исправить проблему?

Это своего рода триггер культурного сдвига. В командах, где разработчики "чувствуют" последствия своих решений:
- Исчезает менталитет "не моя проблема"
- Появляется проактивное мышление о надежности
- Растет эмпатия к операционным командам и пользователям
- Формируется внутренний стандарт качества, который не зависит от внешнего контроля

П.С. Знали бы вы, сколько я контр-аргументов против выслушал по этому поводу
П.П.С. На КДПВ девелоперы заботливо развивают свои микросервисы ^__^

Недавно участвовал в опросе среди 700+ руководителей команд - сегодня прислали результаты, которые показывают, что тимлиды в 2025 году балансируют на грани.

Да, нейросети, автоматизация - все об этом говорят. Но есть другая интересная картина, которая подтверждает мои собственные наблюдения: раньше многие мечтали перейти в лиды, а сейчас, каждый второй задумывается откатиться обратно. Нагрузка выросла, ответственности ещё больше, а разница в зарплате не так уж велика. Опрос показывает, что половина тимлидов ощущают перегруз, а 85% признаки выгорания.
Тут можно посмотреть результаты подробнее: devcrowd.ru/tl-2025/

10 правил хорошего тимлида команды разработчиков

▫️1. Уберите лишние собрания.
Каждый час созвона это минус час фокуса и ещё полчаса на возвращение в контекст текущей задач.

▫️2. Защитите от переработок.
Обсуждения и задачи только в рабочее время, а овертаймы и внеурочные выходы расценивайте как инциденты с разбором причин.

▫️3. Закладывайте реальные сроки.
Важна не только скорость, но и надёжность. Если сроки навязывают и они нереальны, объясните риски и дайте профессиональную оценку.

▫️4. Фильтруйте пожары.
Не каждый срочный влёт критичен. Берите паузу на проверку и защищайте команду от ложных тревог.

▫️5. Подсвечивайте приоритеты.
У каждой правки и нового требования есть цена и глобальное влияние; не меняйте приоритеты без обоснованной ценности.

▫️6. Защищайте от необдуманных решений.
Двигайтесь по целям, отсекайте хотелки без понятной ценности, обосновывайте выбор и предлагайте компромиссы.

▫️7. Избавляйтесь от карго-культа.
Не бойтесь пересматривать процессы и ритуалы. Если флоу работы, статусы или митинги потеряли актуальность, убирайте их или меняйте.

▫️8. Срезайте бюрократию.
Избегайте лишних согласований и узких горлышек, задавайте простые правила и делегируйте решения; автоматизируйте рутину.

▫️9. Помогайте развиваться.
Слушайте запросы, давайте регулярную обратную связь по точкам роста, ставьте цели и выделяйте время на обучение.

▫️10. Подмечайте достижения.
Хвалите за хорошую работу на командных и личных встречах, отмечайте важные успехи выше и делитесь кейсами на всю компанию.

Необязательно быть идеальным лидером. Но вашей команде нужно, чтобы вы её защищали!

Henry Developer

В журнале The HRD вышла моя статья о праве на цифровое бездействие, и как программисту бороться с отвлекающими факторами. Критика приветствуется)

Я тут, немного поразмышлял на тему: "Что делать если вам урезали бюджет".
https://vaiti.io/kak-spasti-proekt-pri-urezanii-byudzheta-rabotayushhie-metody-iz-moej-praktiki/

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

Ставьте лайки если поддерживаете, критикуйте если нет!

За последнее время мне довелось поработать с несколькими редакциями изданий. И вот три разных статьи которые делались почти месяц опубликованы почти в одно время)

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

Как всегда жду критику и ваше мнение!

https://delovoymir.biz/ii-kak-soosnovatel-prakticheskiy-vzglyad-tehlida.html

Посетил интересную лекцию Самата Галимова, ведущего подкаста «Запуск завтра», про историю развития нейросетей.

Джун уже 6 месяцев откликается на вакансии. Каждый день шлёт холодные письма. Ноль результата.

Попросил меня посмотреть его резюме и скинул ссылку. Я не смог её открыть. Спрашиваю у него - он отвечает: «У меня открывается».

Парень разослал 400 писем, даже не зная, что нужно выдать доступ на просмотр в Google Drive.

Я бы посмеялся и списал это на типичную ошибку новичка, если бы не то, как часто я вижу подобные случаи у знакомых. Это реально тревожно

В Твиттере поделились трогательной историей

Проблемы нового VR-шлема от Valve

Меня всегда интересовала тема виртуальной реальности. Ещё в детстве, увидев первый VR-шлем от Sega, я не мог спокойно спать — идея оказаться в любом месте мира (и даже в выдуманном) не вставая с дивана казалась чем-то фантастическим.

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

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

Читать на VC

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

#мысли #ии