• Игры (1). Teenage Mutant Ninja Turtles 3: Manhattan Project

  Jul 22, 2026 games, tmnt

  Давненько я не делал подборок по принципу чисел или постгреса. В этот раз я бы хотел поговорить об играх.

  В детстве я много играл; увидев в первый раз приставку денди, я понял, что это мое. Тогда я не знал, что стану программистом, но какая-то химия возникла. Увы, у меня не было Спектрума или других программируемых платформ; это были обычные денди, сега, первая плойка, комп. Переход на следующую приставку случался редко, примерно раз в пять лет. Жили мы небогато, и я годами копил за заветную железку.

  Я не избегал книг, однако игры развивали меня не меньше. Я запоминал сюжеты, персонажей, рисовал уровни по памяти, придумывал другие концовки. Обожал искать игровые механики, секретные уровни. О персонажах различных RPG мы с приятелем говорили часами, примерно как наша учительница – о персонажах “Войны и мира”. А уж сколько было эмоций, когда мы собирались вчетвером, подключали к первой плойке четыре геймапада и рубились на одном телевизоре!

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

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

  В первом выпуске – замечательная игра для денди под названием Teenage Mutant Ninja Turtles 3: Manhattan Project от 1992 года. В народе – просто “третьи черепашки”.

  

  Злой Шреддер поднял остров Манхэттен в небо, и надо идти выручать жителей. Игра начинается с пляжа, продолжается в море, затем мост, город, канализация, технодром, пещеры, небоскребы и другие локации. На каждом уровне два босса: промежуточный и финальный. Нам предстоит спасти Эйприл, победить обычного Крэнга и его супер-версию, а в финале сразиться с супер-Шреддером.

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

  Каждый, кто играл в третьих черепах, знает, что пройти ее можно только за Леонардо – черепашку с мечами. Дело в том, что боссы в игре очень сильные, и приходится бить их суперударами. И здесь одна тонкость: суперудары других черепах работают по прямой. У Леонардо суперудар объемный: он задевает тех, кто немного выше и ниже на плоскости. Из-за этого можно стоять чуть ниже босса и не ловить его удары, зато наши суперудары будут проходить по нему.

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

  В оригинальном картридже была специальная перемычка между двумя пинами. Игра проверяла, проходит ли между ними электричество, и если нет, значит, картридж пиратский. Самое интересное: проверка случалась не в начале игры, а на середине во время битвы со Шреддером за Эйприл. И нет бы написать: дружище, у тебя пиратский картридж, купи лицензию. Нет – Шреддер становился неуязвимым! Я доходил до него дюжину раз без смертей, лупил по полчаса – и все без толку. Настоящее издевательство над ребенком!

  Так что пройти игру в детстве не удалось. Но лет пять назад я включил эмулятор на Маке, достал с полки геймпад. Качнул ROM, завел черепах – и прошел с первой попытки! Оказалось, я помню порядок уровней, как валить врагов и где они появляются, где лежит пицца для восстановления здоровья и многое другое. Спас Эйприл, победил Шреддера и наконец-то увидел все то, что не удалось тридцать лет назад.

  

  

  

  

  Прохождение:

• Autocommit

  Jul 22, 2026 jdbc, sql

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

  Поведение его следующее. Когда autoCommit — истина, запросы выполняются без явных транзакций. Например, вызываешь UPDATE, и изменения вступают в силу тут же. Если нужна транзакция, явно прописываешь BEGIN и COMMIT. Когда autoCommit ложь, то все интересней. Если в текущий момент транзакции нет, то любой запрос откроет ее. Далее все запросы будут выполняться в транзакции, пока мы не вызовем COMMIT.

  Спрашивается, какое значение у autoCommit по умолчанию? Ответ — истина, но путаницы все равно хватает. Тысячи людей погорели на том, что вызывают INSERT, смотрят в базу – а там фига с маслом. Оказывается, autoCommit был ложью, и перед вызовом UPDATE сработал неявный BEGIN. В конце мы не вызвали COMMIT, транзакция не закрылась, изменения откатились.

  Многие джависты думают, что autoCommit – часть базы данных. И очень удивляются, узнав, что это не так. База данных ничего не знает ни о каком autoCommit. Этого свойства нет в протоколе Postgres, нет его и в протоколах других баз. Во всех случаях он имитируется логическом флагом и бородой if-else. Причем если вы думаете, что все просто, то ошибаетесь: на уровне драйвера проверка на autoCommit случается часто. Скажем, при входе в транзакцию нужно запоминать его прошлое значение и потом восстанавливать. При смене autoCommit надо проверять, находимся ли мы в транзакции и если да, завершать ее. И все это – ради чего?

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

  К тысяче людей, погоревших на autoCommit, присоединился и я. При этом дело было не на Джаве, а в Питоне с библиотекой psycopg2. Все по классике: скрипт подключается к базе и делает UPDATE. Проверяю базу — изменений нет. Оказалось, в psycopg2 слизали autoCommit с JDBC, и по умолчанию он выключен.

  Слушайте, хватит уже! Перестаньте тянуть в библиотеки это старье. Опирайтесь на естественное поведение базы: либо каждый запрос выполняется в неявной транзакции, либо их несколько заключаются в транзакцию. В современных библиотеках никаких autoCommit нет, и слава богу. AutoCommit – это древнейший рудимент из пещерных времен. И в отличие от лишнего позвонка, он колоссально мешает жить.

• Про архитектуры

  Jul 22, 2026 architecture

  Говорят – такая архитектура, сякая архитектура. Масштабируется, учитывает то, другое. Но мне кажется, чаще всего у архитектуры одно оправдание – любопытство разработчика.

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

  Время и сложность расшатывают архитектуры. В начальный момент схема статична, и кажется, что все идет по плану. Но, судя по всему, нарастающая сложность – это базовый закон мира: она прибывает и расшатывает все подряд. Читали книгу “Цель”? Там на примере игры со спичками показано, как ошибка в одном узле завода сказывается на всем производстве. Базовый принцип! Вот и здесь что-то подобное: сложность нарастает и все расшатывает.

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

  Половина всех моих действий уходит на то, чтобы преодолеть проблемы “удачных” архитектур. Все они были кем-то составлены, представлены, защищены перед руководством. И вот я иду в базу не прямым путем, а через три микросервиса; пишу экраны кода, когда при ином подходе понадобилась бы строчка.

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

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

  Сложность не должна опережать удобство. Как у Кнута: предварительное усложнение душит систему.

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

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

• Слоеный дизайн (2)

  Jul 21, 2026 ui, layers

  Пожалуй, стоит дополнить последний пост.

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

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

  

  Посмотрите, как выглядят новости Хабра в RSS-клиенте. Оставлены только заголовки и минимальные данные вроде даты и кнопки “в закладки”. Остальное появляется либо по ховеру, либо клику. Видим, что двадцать с лишним заголовков прекрасно уместились.

  

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

  Для себя я заметил, что никогда не выбираю карточный режим просмотра. Либо полный (заголовок, картинка, текст), либо только заголовок. На мой взгляд, карточка — очень странная форма дизайна. Как правило, она плохо подчиняется какой-то логике: в ней все намешано, она излишне велика и ее пучит изнутри.

  

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

  Поэтому я стараюсь не использовать карточки. И расстраиваюсь, когда вижу их там, где они не кстати.

• Слоеный дизайн (1)

  Jul 21, 2026 ui, layers

  

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

  На картинке выше — главная Хабра на ноуте 14 дюймов. Масштаб 100%, я ничего не уменьшал. Видим, что на экране помещается три с половиной новости. Три с половиной! Это при том, что кроме заголовка нет вообще никакого текста, даже тизера. Единственное, что мне нужно — это заголовок, чтобы прочитать и нажать на него. Итого четыре заголовка на весь экран.

  Посмотрите, как неэффективно занято место. Правая часть плашек пустует. В каждом слое буквально два-три элемента. Метки “Статья” и “Ретроспектива” сидят в отдельных слоях! На каждое слово — сантиметровый слой!

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

  Вдогонку: темная тема плохо сочетается с цветами. Если вы делаете темную тему, то фактически она должна быть черно-белой. Синий, зеленый и другие цвета, которые хорошо смотрятся на белом, должны стать градациями серого. Акценты выделять фоном, обводкой, болдом.

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

  Но увы.

• Подписи к кнопкам

  Jul 21, 2026 ui

  Когда я делаю интерфейс (что случается редко, но все же), то не использую иконки. Вообще, абсолютно. Если кнопка добавляет сущность, пишу “Добавить”. Если удаляет – пишу “Удалить”. То же самое для редактирования, пересылки, отправки на почту, загрузки и так далее.

  Почему? Да потому что надоело. Иконки и пиктограммы – это игра, в которой не выиграть. Родной язык мы учим с первых месяцев жизни, а многие иконки увидели будучи взрослыми. Что проще понять: надпись “переслать” или изогнутую стрелку?

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

  Что означает конверт? Написать письмо? Как бы не так: получить почту. Для отправки письма служит карандашик.

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

  Да, слово “Удалить” занимает больше места, чем мусорный бак. Но ни разу не было такого, чтобы приходил пользователь и говорил: друг, замени на иконку, места не хватает. Тысячу раз было обратное: вижу иконку и не понимаю, что она делает. Подвожу мышь и читаю подсказку.

  Особенно забавляют ребята, которые делают два в одном: иконка и надпись. Например, сначала мусорный бачок, а потом Delete. Зачем одно, если есть другое? Ты бы еще шрифтом Брайля подписал или рунами инков!

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

  Раньше в некоторых программах был выбор: использовать иконки или надписи. Из того, что запомнилось – это, внезапно, Gmail и приложения Мака вроде Preview. Скриншотов под рукой нет, но я пользовался этой опцией и клянусь, что так и было. Разумеется, с обновлениями фичу похоронили.

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

  То же самое относится к дорожным знакам. В России 8 групп дорожных знаков, а всего их около 300. Сомневаюсь, что типичный водитель распознает хотя бы треть из них. Почему бы не делать знаки текстом? Остановка запрещена. Парковка только в праздничные дни. Проезд закрыт.

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

  Текст – это просто и дешево. Не бойтесь текста!

• Микросервисы и базы

  Jul 21, 2026 programming, sql, database, postgres

  Когда говорят “микросервисы”, мне хочется смеятся. Когда говорят, что у каждого микросервиса своя база данных, я хочу плакать.

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

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

  Неважно, насколько красивый у вас лендинг или сколько библиотек в js-бандле. Важно, сколько фирма продает, и как быстро, и что именно, и когда. На все эти вопросы отвечает отчетность. Момент, когда начальство ее потребует, является лишь вопросом времени.

  Спрашивается: имея пятнадцать баз, разбитых по сервисам, как вы сделаете отчетность? Взять хотя бы такую мелочь как отчет продаж: сколько продали за последний год и кому. Это join трех-четырех таблиц. Если они раскиданы по базам, как вы его соберете?

  Технически можно вызвать сервис пользователей 100 раз, выгребая по 1000 записей. Потом дернуть 1000 раз сервис продаж, потом 200 раз сервис категорий и так далее. Нагрузить сеть и положить инфраструктуру ди-досом. Соединять сущности в приложении по словарям, умирая от нехватки памяти. А можно иметь одну базу и запрос, который сделает то же самое за секунду.

  Без консолидированной базы отчетность невозможна. Если у вас 15 баз, понадобится 15 репликаций, которые будут сливать в нее данные. А это – 15 процессов, которые нужно мониторить. Вдруг одна репликация отвалилась? Как вы об этом узнаете?

  В Постгресе и других базах есть схемы – аналог пространств имен в языках программирования. Две сущности с одним именем, но в разных схемах не пересекаются. Таблица users в схеме accounts хранит пользователей системы (покупателей), а в схеме backoffice – членов персонала.

  Естественно держать сервисы в одной базе, но разных схемах. У каждого сервиса машинное имя и соответствующая схема, например accounts, sales, backoffice, management, analytics и другие. В них – таблицы, вьюхи и другие сущности.

  Когда мы пишем select * from users, база должна понять, какой схеме принадлежит users. Для этого используется глобальный параметр search_path – список схем, в которых ищутся сущности без явно указанной схемы. По умолчанию он равен "$user",public. Схема "$user" – особая по двум причинам. Во-первых, в ее названии есть доллар, из-за чего ее берут в двойные кавычки. Во-вторых, $user означает имя текущего пользователя, например ivan. Это значит, что сначала Postgres проверит, есть ли таблица ivan.users, затем public.users, а если ничего не найдено – кинет ошибку.

  Схемы дают контроль над доступом. Писать в схему может лишь сервис-владелец, например пользователь accounts пишет в accounts.user, но не в sales.products. Данные из других схем выборочно дают на чтение. Скажем, сервису accounts нужны категории товаров. В этом случае дается GRANT SELECT на таблицу sales.categories для пользователя accounts. Эту таблицу можно прочитать или приджойнить в запросе.

  Удобно, когда каждый сервис подключается под своим пользователем. Если это сервис accounts, база будет искать таблицу users в accounts и в public. Таблицы, которые принадлежат текущему сервису, можно писать без схемы, а для таблиц-соседей указывать их. Например в запросе ниже видно, что users – это accounts.users (подключение под пользователем accounts), а профили приходят из схемы profiles, к которой нам дали доступ на чтение.

  select * from users u
  join profiles.profiles p on u.id = p.user_id
  

  Такое решение исключает ситуацию, когда вместо прямого запроса мы идем в обход: вызываем сервис и получаем результат, а затем соединяем данные в приложении. Последнее – долго, хрупко и не масштабируется.

  На этом месте говорят: если база упадет, перестанут работать все сервисы. Решение – делать так, чтобы не упала! Проверяйте запросы перед вводом в эксплуатацию, смотрите планы, гоняйте на тестовых данных. Мониторьте базу, наказывайте тех, кто шлет кривые запросы. Введите общие стандарты, примеры, документацию, чтобы было куда направлять людей. Сюда же относятся резервные копии и горячее переключение, но это уже ближе к devops.

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

• Глава 7. Отчеты, функции, расписание

  Jul 20, 2026 postgres, json, book, sql

  Главы

  1. Введение в документы
  2. Базовые возможности JSON
  3. JSON в таблицах
  4. Индексирование JSON
  5. Ограничения в документах
  6. Язык путей JSONPath
  7. Отчеты, функции, расписание
  8. Функции на языке Python
  9. Версионирование и архивация документов
  10. Релевантный поиск

  Содержание

  • Главы
  • Проблема вложенности
  • Простые отчеты
  • Функция jsonb_table
  • Параметры в JSON Path
  • Отчеты с группировкой
  • Рекурсивные документы и запросы
  • Знакомство с функциями
  • Схемы и префиксы
  • Характеристики функций
  • Примеры функций
  • Рекомендации к функциям
  • Временные функции
  • Тестирование функций
  • Выгрузка отчетов
  • Отчеты и представления
  • Задачи по расписанию
  • Другие применения pg_cron

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

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

  Чем крупнее компания, тем больше в ней участников, заинтересованных в офисном формате данных. Это руководоство, менеджмент, отделы анализа и другие. Им нужна выгрузка данных по разным критериям в разрезе тех или иных полей — другими словами, отчетность. Какие-то отчеты проверяют вручную: каждое утро начальник открывает файл Excel и оценивает показатели. Другие предназначены для импорта в программы, созданные для моделирования и сложных расчетов. В них аналитики строят проекции, кубы, проверяют гипотезы.

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

  • показать заявки со статусом “в работе” за последние три месяца по убыванию даты создания.
  • Показать просроченные заявки. Просроченной считается та заявка, что не получила финальный статус в течение трех месяцев с момента создания. Финальным статусом считаются “одобрена”, “отклонена”, “отозвана”.
  • Показать отделы, которые обработали больше заявок в текущем квартале.
  • Для одобренных заявок найти пользователей, которые над ними работали.

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

  Read more →

• Is AI Profitable Yet?

  Jul 5, 2026 life, ai

  Еще один сайт-страничка называется Is AI Profitable Yet?. За указанным заголовком следует лаконичное No, а ниже – фирмы вроде Гугла, Амазона и так далее. Напротив каждой указано, сколько денег они потратили на эй-ай и сколько заработали.

  

  Автор утверждает, что информация взята из официальных источников. В подвале есть выпадашка с надписью Sources & References, и если ее нажать, откроются ссылки. Разумеется, я их не проверял и не ручаюсь за достоверность. Сайт я рассматривают только как интересную инфографику.

  Особая ситуация с Nvidia. Эти ребята – единственные, у кого зеленый столбик опережает красный, причем с двойным запасом. Nvidia, конечно, молодцы. У них даже не звездный час, а звездные 15 последних лет. Сначала был майнинг, потом машинное обучение, потом голосовые модели, а сейчас еще агенты — при этом не исключая старые добрые игры, рендер, VR. Все это растет экспоненциально, строители не успевают заливать бетон под датацентры.

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

  Поживем – увидим.

• Как работать?

  Jul 5, 2026 life, work

  У меня простой вопрос: как вообще работать? Я о том, что если следить за всеми потоками информации, то весь день я просижу в корпоративных мессаджере и почте. Редактор и терминал я ни разу не открою.

  Смотрите, есть почта. Туда валится Джира, уведомления из Teams, правки к статьям в Вики, внутренние новости, тренинги, вебинары. В Teams – дюжина чатов и каналов, не считая личных сообщений.

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

  Эта заметка не о том, чтобы собрать советы а-ля “настрой почту” и “отключи уведомления”. Все это я применяю и готов написать сотню подобных советов. Я говорю о другом: никто не учит нас находить время для работы. Скажем, мне накидали три митинга, а кто научит тому, чтобы поработать между ними?

  Я научился, а кто-то нет. Или я думаю, что научился, а сам протупил час на ровном месте.

  Полтора часа неотрывного кодинга – что-то из области фантастики. Чаще всего это случается, когда у заказчика праздник (и становится моим личным праздником).

  Мне кажется, весам пора качнуться в другую сторону. Должно прийти понимание, что сотрудникам нужно время, когда их никто не отвлекает. Неужели полтора часа спокойной работы – такая роскошь? Что мы проморгали, если очутились в такой ситуации?

← Страница 3 из 115 →