Что мы увидим, если посмотрим на монитор разработчика в разгар рабочего дня? Там наверняка будет открыта IDE, Git, таск-трекер, документация, корпоративный мессенджер. И еще какая-нибудь мелочевка — в зависимости от того, что принято в команде.

И всегда понятно, что из этого зачем нужно. Код было неудобно хранить — появился Git. Проект стало долго собирать и проверять вручную — автоматизировали сборку и тесты. Понадобилось следить за тем, что происходит с сервисами после релиза, — появились системы мониторинга. Инфраструктура стала слишком сложной, чтобы каждый разработчик разбирался с ней самостоятельно, — начали появляться внутренние платформы.

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

В Stack Overflow Developer Survey 2025 разработчиков впервые попросили посчитать, сколько отдельных инструментов они используют в работе. Из 27 378 ответивших 54% назвали шесть и более приложений или платформ. Операционная система и браузер в этот подсчет не входили. Для сайд-проектов картина оказалась несколько другой —  65% из 25 391 разработчика используют пять инструментов или меньше.

Согласитесь, шесть инструментов — не так уж много. Особенно если учесть, что речь, вообще-то, идет про современную разработку.

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

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

Потихоньку копятся стресс, нереализованные амбиции и внутреннее несогласие с окружающим миром. Раздражают решения конкретного продакт-менеджера. Бесполезные дейлики. Обязательная корректность в любом рабочем разговоре. А в финале приходит отвращение ко всей индустрии ИТ, превратившейся из творческого полигона в конвейер, штампующий коммерческую посредственность.

Особенно остро это бьет по тем, кто отдал профессии порядка 15-20 лет. Поколению, которое до сих пор относится к своей работе как к особому виду искусства, тошно от коллег, пришедших только за деньгами и не желающих по-настоящему учиться и развиваться.

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

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

Вы сможете сходу ответить на вопрос, почему в результате простейшей операции 0.1 + 0.2 в консоли браузера выведется число 0.30000000000000004?

Мы привыкли списывать такие причуды на Великие и Ужасные Особенности Языка Программирования. Ну вот работает оно так, и всё.

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

В этой статье мы поговорим об особенностях машинной арифметики: от костылей в бортовом компьютере «Аполлона» до проблемы 2038 года. Заваривайте чаёк покрепче, и мы начинаем.

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

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

Вся история микрокомпьютеров, расцвет которых пришелся на начало 1980-х, фактически сводится к борьбе программистов и инженеров за каждый свободный байт. Именно оперативная память определяла границы дозволенного. Игры и прикладное ПО усложнялись, каждая новая функция отрезала кусочки от объема ОЗУ, доступного пользователю. Приходилось хитрить, выдумывать нестандартные подходы и всячески изворачиваться, чтобы втиснуть свой код и ресурсы в скромные 48, а то и 16 килобайт оперативной памяти.

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

Что на самом деле защищает наши данные? Снапшоты, которые создаются за секунды и позволяют мгновенно откатиться к предыдущему состоянию? Регулярные резервные копии, которые хранятся на отдельном хранилище? Или репликация, которая обеспечивает непрерывность работы даже при сбое площадки?

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

В этой статье расскажем, почему снапшот — это вообще не бэкап, почему репликация не заменяет резервное копирование, какие требования предъявляются к современной системе защиты данных, и покажем, как эти принципы реализованы в связке VMmanager и RuBackup.

На первый взгляд ELIZA Джозефа Вейценбаума кажется чем-то примитивным. Практически набором костылей из регулярных выражений, который тупо менял местами «я» и «вы» и иногда задавал уточняющие вопросы. Да, в массовом сознании она так и осталась игрушкой из 60-х, наивной попыткой обмануть пользователя парой строк кода. И если вы думаете, что про ELIZA уже все давно сказано и разжевано, спешим вас удивить.

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

ИИ увеличивает продуктивность разработчиков на 55% — по крайней мере, к такому выводу пришли в этом исследовании.

Неужели мы наконец-то нашли вот ту самую пушку, которую индустрия ждала не один десяток лет? Бери инструмент, закрывай задачи в два раза быстрее и иди пить кофе трать оставшееся время на саморазвитие или что-то в таком духе.

Но так ли это на самом деле? Почему с ИИ код действительно пишется быстрее, а вот ревью — затягивается? Почему фичи релизятся быстрее, а поддерживать их становится сложнее? Давайте разберем, почему так происходит, что на самом деле стоит за громкими цифрами и где проходит тонкая грань между делегированием рутины и потерей экспертизы.

Техдолг приносит бизнесу (а нередко и самим айтишникам) ощутимые потери. Например, по данным McKinsey, он отъедает порядка 40% ИТ-бюджета. И время тоже — по оценкам исследования CAST, уровень глобального техдолг вырос настолько, что суммарное время на его исправление оценивается в 61 млрд рабочих дней — и это еще довольно консервативная цифра.

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

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

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

Привет, Хабр!

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

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

В наши дни поиск информации стал почти скучен и почти тривиален. На 90% запросов и вовсе можно получить ответ от встроенной в поисковик нейросети, без необходимости прокликивать пару десятков ссылок. Разумеется, так было не всегда. Автору статьи, например, до сих пор непривычно пользоваться нейроподсказками. Прочитать текст по ссылке своими глазами  —  бесценно, если требуется на 100% точная информация.

Поколение 35+ наверняка помнит, как интернет выглядел без Google и Яндекса. Кто-то был завсегдатаем школьной или районной библиотеки. Кому-то приходилось каталогизировать и размечать конспекты учебных лекций вручную. Казалось бы, это не слишком связанные вещи — где интернет-поиск и где допотопная картотека. Но без второго не было бы первого.

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

Для целого поколения пользователей этот маленький квадратик в левом нижнем углу экрана стал главным символом персонального компьютера. Да что там компьютера, целой эпохи! 

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

Как появилось меню «Пуск» и какую роль в этом сыграли шимпанзе — расскажем в этой статье!

Вы наверняка ловили себя на 100% погружении в задачу — казалось бы, только-только ее открыли, а сейчас она уже решена. В это время вас не отвлекали ни мессенджеры, ни почта, ни рабочие созвоны. Именно такое называют состоянием потока. Когда концентрация — ваше второе имя, а фокус удерживается сам собой.

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

В этой статье попробуем разобраться:

— существует ли на самом деле то самое состояние потока или это просто красивый термин?

— почему разработчики так легко его теряют и сколько реально времени уходит на возвращение к задаче после отвлечения?

— какие простые организационные и технические практики помогают удерживать фокус и погружение?

Есть мнение, что парное программирование (далее — ПП) автоматически дает более качественный результат — код лучше, багов меньше. А вот на практике нередко получается наоборот — подход, который должен был бороться со злом, приводит к конфликтам, усталости и выгоранию. Кто виноват?

Оказывается, на эффективность парного программирования влияет не только скиллы участников процесса, но и их психологическая совместимость. 

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

Многие из нас до сих пор нежно хранят в своем сердце воспоминания о Windows XP. И есть за что. Дружелюбная к пользователю, надежная (особенно после 98-ой и «линолеума»), да и просто ставшая для многих проводником в мир компьютеров — именно такой и была эта ОС. А вот пришедшую ей на смену Vista ругают до сих пор. В первую очередь, из-за низкой стабильности, которая бросалась в глаза после отточенной сервис-паками XP. Однако между XP и Vista есть еще кое-что. Проект, который не стал успешным релизом, но который на десятилетия определил устройство Windows. И имя ему — Longhorn. Почему эта задумывавшаяся революционной ОС так и не вышла, как амбиции столкнулись с реальностью и какие идеи из той эпохи до сих пор живут в «винде» — разбираемся в этой статье.

Интуиция подсказывает — чем больше пул-реквест, тем выше соблазн по-быстренькому пробежаться глазами по коду и аппрувнуть изменения. Предлагаем вам вместе с нами проверить утверждение из заголовка! В статье посмотрим, к чему пришли исследователи, проанализировавшие 50К+ пул-реквестов, обсудим, какие когнитивные искажения на это влияют, и разберем, как изменилась ситуация с появлением ИИ-помощников. Поехали!

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

Но в сегодняшней статье мы не будем писать о том, как такая (вроде) очевидная штука позволила продлить жизнь огромному количеству мониторов. Вместо этого мы проследим их путь от научной фантастики 60-х до аркадных автоматов, легендарных After Dark и 3D Pipes. Узнаем, почему на Macintosh летали тостеры и как на Windows появились легендарные «Трубы». И попробуем ответить на вопрос — умерли ли скринсейверы на самом деле или просто ждут своего часа?

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

Зачем мы вообще решили вам это рассказать? Понимание механизмов работы мозга помогает:

— оптимизировать процесс обучения под реальные человеческие лимиты, а не до отсечки в черепной коробке;

— отличать нормальный процесс адаптации от признаков когнитивной перегрузки;

— использовать биологически обоснованные практики на благо себя любимого.

В статье разберемся, действительно ли у программистов — особый мозг, что происходит в голове, когда мы учимся кодить, и как помочь себе учиться (не только программированию) эффективнее и без ущерба для здоровья. Поехали!

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

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