Обсуждал тут улучшения своих сайтиков с чатом жопотэ, дипсиком, перплексити и другими сказителями. Идей роботы озвучили очень много, и внезапно я понял, что нужно возвращаться к истокам: взять и переписать свой бложек и лендинг студии обратно на Turbo Pascal Друпал.

Эксперимент с October CMS был по-своему прекрасен, узнал и сделал много нового, и CMS неплохая. Но ряд вещей, которые я хочу сделать, на Друпале сделать тупо в 2–3 раза быстрее.

Перенести в принципе недолго, сделать всё на вьюзах, а шаблоны фронта в October уже сделаны на twig. Можно даже управиться к Новому году. Надо только понять, к какому.

Ради этого стоило изобретать генеративные нейросети!

Пишите тесты до, а не после!

Начал тут из любопытства китайский на дуолингве. А там почти сразу ероглифы эти надо не только читать, но и даже писать.
Как вообще китайцы всё это ханьцзы запоминают, невозможно же. Должны быть какие-то мнемонические правила. Ведь должны быть?

Важное пятничное напоминание:

Что один программист сделает за месяц, два программиста сделают за два месяца.

Воскресная открыточка на день разработчиков по white label. Такого дня в календаре почему-то нет, а хорошо бы был.

Практическая задачка про командную разработку

Допустим, есть тимлид и он поставил разработчику задачу. Достаточно сложную. Описал концепцию, предложил известный метод А для решения.

Разработчик изучает концепцию и молча избирает для решения метод Б (тоже известный). Выкатывает результат. Тимлид читает, удивляется смене концепции, но видит, что метод Б может сработать как минимум не хуже А. Поэтому пропускает результат в тестирование, тем более что проверить уже реализованный метод Б быстрее, чем сразу требовать вернуться к A.

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

Разработчик переключается на изначально предложенный метод А. Метод А срабатывает как ожидалось, задачу удается решить, но с превышением оценки на ~80% из-за потраченного на Б времени.

Система S — внешняя, узконишевая, почти безальтернативная и довольно инновационная. Найти разработчиков с опытом в ней непросто. Документация к S есть, но неполная. Как водится, её неполнота усугубляется с каждым обновлением. По сути разработчики работают с S раз в жизни — если придётся. У тимлида есть прямая линия с CEO системы S, но она не предполагает ежедневных бесед по любому поводу.

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

Ниже опрос.

Обсуждение бесполезности тимлидов на одной из платформ, куда я запостил «чудовищную ошибку» выше, напомнило старый анекдот.

Токарь вдумчиво протирает гаечный ключик тряпочкой. К нему подходит начальник цеха:
— Петров, [censored]! Ты какого лешего домой так рано собираешься? Время всего 17:30!
— Понимаешь, я пока ключик тряпочкой протру, пока станок железной щеточкой почищу, пока ручки мыльцем отмою, пока переоденусь… Вот как раз и конец рабочего дня наступит.
— Нет, Петров! Считаю, что это неправильно! Вот я, например, собираюсь с работы ровно в 18:00.
— А тебе-то что собираться? Рот закрыл и пошёл…

Надо написать что-нибудь ещё жизнеутверждающее про пользу тимлидства.