Сохранёнки программиста

Разработчик Рич Уайтхаус написал жёсткую статью о том, почему он полностью разочаровался в опенсорсе и перестал писать бесплатный код. По его мнению, вся эта культура в итоге просто помогает крупным корпорациям обесценивать работу обычных инженеров.​Главные мысли из его лонгрида:— компании годами используют открытые репозитории как бесплатную ресурсную базу, при этом регулярно забивая на лицензии;​— бум нейросетей только добил ситуацию, корпорации молча скормили своим моделям десятилетия чужого труда без оглядки на авторское право;​— внутри самих опенсорсных комьюнити процветает токсичность, синдром вахтера и бесконечные споры ради раздутого эго мейнтейнеров.​Уайтхаус уверен, что идея писать код на общее благо отлично звучит только в теории. На практике любые полезные наработки быстро и безвозмездно забирают гиганты индустрии. В итоге это бьёт по нам самим. Ценность разработчиков на рынке падает, потому что бизнесу становится выгоднее вкладываться в серверы и ИИ, бесплатно обученный на нашем же коде.Полная статья: https://richwhitehouse.com/index.php?postid=77@prog_stuff

Scientific American собрали свежую статистику о том, как нейросети влияют на жизнь разработчиков. Изначально все надеялись, что ИИ разгрузит инженеров, но реальные цифры показывают обратную картину: программисты стали работать больше и чаще перерабатывать по вечерам.​Главные причины такого парадокса:— Падает стабильность релизов. Нейросети выдают код мгновенно, но его нужно тщательно проверять. Отчёт DORA подтверждает, что активное использование ИИ напрямую связано с ростом откатов и горячих фиксов на проде.​— Растут ожидания руководства. Бизнес замечает ускорение и требует закрывать больше задач. В итоге инженеры берут дополнительный объем, а количество их коммитов в нерабочие часы выросло почти на 20%​— Усложняется отладка. Инженеры объективно хуже понимают сгенерированную логику. Когда такой код ломается, на поиск причин и исправление багов уходит гораздо больше сил.​Получается, что инструменты действительно ускоряют написание новых блоков, но вся экономия времени полностью сгорает на этапах тестирования и ревью. А если вы начинаете писать код быстрее, в качестве награды менеджеры просто накидывают вам больше новых тикетов.Полная статья: https://www.scientificamerican.com/article/why-developers-using-ai-are-working-longer-hours/@prog_stuff

Если вы когда-нибудь работали в кровавом энтерпрайзе на Java, этот репозиторий может вызвать у вас флешбеки и легкую панику. Разработчики создали пародийный проект FizzBuzz Enterprise Edition — ту самую задачу с собеседований про деление чисел на 3 и 5, но написанную «серьёзными бизнесменами для серьёзных бизнес-целей».​Вместо десяти строк кода авторы наворотили гигантскую архитектуру. Внутри бесконечные вложенные папки, десяток фабрик, интерфейсы для интерфейсов и классы с названиями в духе FizzBuzzOutputGenerationContextVisitor.​Отдельный вид искусства в этом проекте — раздел Issues. Пользователи активно подыгрывают авторам и создают гениальные тикеты. Например, кто-то пожаловался, что код написан слишком качественно и потребовал ухудшить его, чтобы соответствовать реальным индустриальным стандартам. Или предлагают уволить бизнес-аналитика, потому что он слишком понятно объяснил задачу, и требуют добавить больше уровней абстракции, чтобы никто не смог найти, откуда импортируется код.@prog_stuff

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

Посмотрите на этот безумный проект. Полноценный эмулятор процессора архитектуры x86 на чистом CSS. Никакого JavaScript или WebAssembly, все вычисления происходят исключительно силами браузерного движка стилей.Как это реализовано технически:— эмулятор исполняет реальный машинный код для процессоров 8086;​— тактовый генератор построен на CSS-анимациях, поэтому система работает автономно и не требует от пользователя постоянно водить курсором по экрану;​— логика работает благодаря новым спецификациям CSS, таким как условные операторы if(), стилевые запросы и кастомные функцииВы можете запустить в этом эмуляторе собственные программы. Достаточно написать код на C и прогнать его через GCC с помощью скрипта из репозитория автора. На выходе вы получите готовый HTML-файл со стилями, внутри которого будет крутиться ваш бинарник.Практического применения у проекта нет, производительность получается крайне низкой. Зато это отличная демонстрация того, что современный CSS действительно стал тьюринг-полным языком программирования. Из-за использования экспериментальных функций запустить демку пока можно только в браузерах на базе Chromium.@prog_stuff

Разработчик из Mozilla Габриэле Свельто поделился технической статистикой о причинах падений Firefox. Некоторое время назад команда инженеров внедрила в браузер алгоритм для анализа краш-репортов, который умеет выявлять одиночные искажения битов в памяти.Собранные данные показали неочевидную картину:— система точно зафиксировала битфлипы в 5% всех отчётов об ошибках;— по расчётам команды реальная доля таких инцидентов доходит до 10%.Получается, что каждый десятый сбой браузера происходит не из-за ошибок в коде, а из-за физических проблем с оперативной памятью на устройствах пользователей. На обычных компьютерах крайне редко используется память с поддержкой коррекции ошибок (ECC), что неизбежно приводит к случайным искажениям данных.Для нас как для разработчиков это полезный пример. Когда вы долго пытаетесь воспроизвести странный плавающий баг по логам клиента, проблема может скрываться не в написанной логике. Иногда приложение падает исключительно из-за случайного переключения одного бита на аппаратном уровне.@prog_stuff

Победителями премии Тпрогер 🐀становятся...Здесь играет барабанная дробь и интригующая музыка... Вам нужно только выждать драматическую паузу перед объявлением победителей — в каждой номинации он один, и определяется большинством голосов. Готовы?В номинации «Продукт года» золотая мышь достается компании:🐀NetVision за платформу интеллектуального мониторинга СИМ.В номинации «Облачный продукт года» побеждает компания:🐀Гравитон с паком виртуализации «Гелиус»Звание «IT-ивент года» вручается компании:🐀Островок! за О!ХакатонИ в категории «Дизайн года» первое место занимает компания:🐀AcademiaDev за интерактивную инсталляцию.Каждый ваш лайк, голос влияли на исход премии. Давайте поддержим всех — ставьте 🏆участникам, которые хоть и не заняли призового места, но точно остались в сердечке.И 🔥, если хотите аналогичных активностей и готовы выбирать еще!

Никого не повышают за простотуИнженер A делает фичу за два дня: пишет 50 строк понятного кода, тестирует, выкатывает.Инженер B берёт ту же задачу, но строит «масштабируемую архитектуру»: добавляет pub/sub, новые абстракции и фреймворк для конфигурации. Тратит три недели.На performance review работа B звучит как готовый кейс: «спроектировал масштабируемую событийно-ориентированную архитектуру, внедрил переиспользуемый слой абстракций». Работа A звучит как «сделал фичу X». Никто не получает повышение за ту сложность, которой он избежал.Индустрия системно поощряет оверинжиниринг:— На собеседованиях кандидаты рисуют сложные схемы с микросервисами и шардированием, потому что простое решение с одной БД кажется интервьюерам недостаточно «умным»— На код-ревью простые решения обрастают абстракциями из-за вопросов коллег «а не стоит ли заложиться на будущее?»В итоге код становится «профессиональнее», но не приносит пользу быстрее, а поддержка усложняется. Настоящая сеньорность — это не знание большего количества паттернов, а понимание, когда их не нужно применять.Автор даёт совет: решение не строить сложную систему — это важное инженерное решение. Его нужно документировать. Вместо «сделал фичу X» пишите: «Оценил три подхода, включая event-driven архитектуру. Определил, что простое решение покрывает все текущие требования. Выкатил за 2 дня, 0 инцидентов за полгода».Статья целиком: https://terriblesoftware.org/2026/03/03/nobody-gets-promoted-for-simplicity/@prog_stuff

Пару недель назад Андрей Карпаты написал скрипт MicroGPT — полноценную языковую модель с нуля на чистом Python, без единой внешней зависимости или библиотеки. В 200 строк уместился весь алгоритм, на котором работают большие модели вроде ChatGPT.Разработчик GrowingSWE сделал из этого скрипта потрясающий интерактивный лонгрид. Он разобрал код по кусочкам и визуализировал каждый шаг прямо в браузере.Каждый шаг алгоритма разобран и визуализирован прямо в браузере. Вы можете руками:— Подвигать ползунки логитов и посмотреть, как Softmax превращает их в вероятности.— Пройти по шагам backpropagation и увидеть, как модель понимает, куда крутить веса.— Изучить матрицу Attention: как разные «головы» учатся обращать внимание на разные части слова.​Разница между этим скриптом и ChatGPT — только в масштабах (вместо триллионов токенов тут имена, а вместо сотен слоёв — парочка). Базовый цикл абсолютно тот же.Интерактивный разбор: https://growingswe.com/blog/microgpt@prog_stuff

Лучший инженер ≠ хороший менторВ педагогике есть термин «проклятие знания»: когда знаешь что-то слишком хорошо, ты буквально теряешь доступ к тому, каково это — не знать. Именно поэтому крутой разработчик может отлично писать код, но не уметь объяснить джуну, как он думает.Мысли в статье такие:🔘1-on-1 с сеньором в большинстве команд — это просто статус по проекту: как фича, есть ли блокеры. Выглядит как менторство, не является им🔘Джуны задают технические вопросы: как алгоритм, почему запрос медленный. Но реальные тормоза роста обычно нетехнические: как работать с неопределённостью, как управлять ожиданиями, как не соглашаться с менеджером🔘Эти вещи не спрашивают, потому что не знают, что они существуют. Нельзя попросить помощи с тем, о чём не подозреваешь🔘Хороший ментор видит не только что джун делает, но и что тот не замечает в своих действиях. Это отдельный навык, который никто не развивает, потому что никто не просил🔘Сеньора поставили менторить не потому что он умеет учить, а потому что он хорошо пишет кодСтатья Simon Wang на Medium: https://levelup.gitconnected.com/stop-expecting-your-best-engineer-to-be-a-good-mentor-05eba3ff6c98@prog_stuff