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

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

Эффект программирования по Хемингуэю

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

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

Исследования продуктивности программистов

Исследование Маттиаса Фолькса и его коллег из Northeastern University, опубликованное в журнале "Empirical Software Engineering", анализировало соотношение между количеством написанного кода и его долгосрочной ценностью для проекта. Исследование под названием "The Productive Programmer: What Makes Top Performers Different" показало, что самые эффективные разработчики часто пишут меньше кода, но создают более чистые, модульные и легко поддерживаемые решения.

Microsoft Research под руководством Кэтрин Стоквуд (Catherine Stockwood) провела масштабное исследование "Productivity Patterns in Software Development", где отслеживались биоритмы продуктивности более 500 разработчиков на протяжении 18 месяцев. Исследование выявило, что около 72% разработчиков имеют четкие циклы когнитивной продуктивности, которые повторяются изо дня в день. Утренние часы (с 9:00 до 11:30) оказались оптимальными для задач, требующих аналитического мышления, в то время как период с 14:00 до 16:00 был особенно продуктивен для творческого решения проблем.

Японские практики в разработке программного обеспечения

Практика "мокусо" (黙想, mokusō) применяется в некоторых японских технологических компаниях, включая подразделения Rakuten и Fujitsu. В книге Йошихиро Кавано "Zen and the Art of Software Development" описывается, как команды разработчиков начинают каждую рабочую сессию с 2-5 минут созерцательного размышления, что помогает очистить сознание и сфокусироваться на предстоящей задаче.

Концепция "ма" (間, ma) — пространства между объектами — нашла отражение в подходе к проектированию интерфейсов и программной архитектуры, что подробно описано в исследовании Хироши Накано "White Space in Code: The Aesthetics of Programming", опубликованном в IEEE Transactions on Software Engineering.

Психологическая инертность и минимализм задач

Термин "психологическая инертность задач" был введен исследователями Роем Баумейстером (Roy Baumeister) и Э.Дж. Маскикампи (E.J. Masicampo) из Университета Флориды в их работе "Consider It Done! Plan Making Can Eliminate the Cognitive Effects of Unfulfilled Goals". Они обнаружили, что незавершенные задачи создают постоянную когнитивную нагрузку, известную как "эффект Зейгарник", и что простое планирование времени для выполнения задачи может значительно снизить эту нагрузку.

Заключение

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

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

🫥 Cross Join

Пересмотр алгоритмов хеш-таблиц: студент опроверг 40-летнюю гипотезу

В мире алгоритмов произошло знаменательное событие, которое может изменить наше понимание хеш-таблиц. Эндрю Крапивин (студент Ратгерского университета), опроверг гипотезу, которую учёные считали верной на протяжении 40 лет.

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

Существует два основных метода решения проблемы коллизий:

- Метод цепочек (chaining) — при коллизии элементы с одинаковым хеш-значением помещаются в связный список или другую вспомогательную структуру данных. Этот метод требует дополнительной памяти для хранения указателей.
- Открытая адресация (open addressing) — использует только один массив без дополнительных структур. При коллизии алгоритм ищет другую свободную ячейку в массиве по определённой стратегии.

Открытая адресация имеет ряд преимуществ:

- Более эффективное использование памяти без накладных расходов на указатели
- Лучшая локальность данных, что улучшает производительность кэша процессора
- Отсутствие необходимости в динамическом выделении памяти
- Предсказуемые характеристики производительности

Классические стратегии поиска в открытой адресации

В хеш-таблицах с открытой адресацией используются различные стратегии для определения последовательности проверки ячеек при коллизии:

Линейное пробирование — последовательная проверка следующих ячеек (h(key) + 1, h(key) + 2, ...)
Квадратичное пробирование — проверка ячеек с квадратичным смещением (h(key) + 1², h(key) + 2², ...)
Двойное хеширование — использование второй хеш-функции для определения шага
Случайное пробирование — применение псевдослучайной последовательности для выбора следующей ячейки

Гипотеза Яо и её опровержение

В 1985 году Эндрю Яо, будущий лауреат премии Тьюринга, сформулировал гипотезу, согласно которой в хеш-таблицах с определённым набором свойств оптимальной стратегией поиска элемента или свободного места является случайное пробирование. Он также утверждал, что в наихудшем случае, когда таблица почти полностью заполнена (на 99%), для поиска последнего свободного места потребуется время, пропорциональное степени заполненности (x).

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

Дополнительное открытие о "нежадных" хеш-таблицах

Продолжая исследования с коллегами Мартином Фарач-Колтоном и Уильямом Кушмаулем, Крапивин сделал еще одно важное открытие, касающееся другого аспекта хеш-таблиц.

Яо в своей работе 1985 года доказал, что для так называемых "жадных" хеш-таблиц (где новый элемент всегда помещается в первую доступную ячейку) среднее время поиска не может быть лучше log x. Это было математически доказанное ограничение для данного класса хеш-таблиц.

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

Значение открытия

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

🫥 Cross Join
⠀

Оказывается, компилятор typenoscript переписали на Go

Выбор Go был обусловлен несколькими ключевыми факторами:

Структурная совместимость с существующим кодом — Go позволил сохранить структуру и семантику оригинального кода на JavaScript/TypeScript. Это критично, так как команда планирует поддерживать обе кодовые базы параллельно, и близкое сходство упрощает перенос изменений между ними.

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

Сбалансированное управление памятью — Go отлично контролирует расположение и выделение памяти (как на уровне объектов, так и полей), не заставляя при этом постоянно думать об управлении памятью. Наличие сборщика мусора в данном случае не создаёт проблем, так как компилятор не имеет строгих ограничений по задержкам.

Эффективная работа с графовыми структурами — компилятор TypeScript интенсивно использует обработку графов и обход деревьев, а Go делает такие операции эргономичными.

Производительность — переписанный на Go компилятор показал 10-кратное ускорение по сравнению с оригинальной версией.

Как отмечает Андерс Хейлсберг (ведущий разработчик TypeScript), команда рассматривала и другие языки, включая C# и Rust, но Go оказался оптимальным выбором для данной конкретной задачи. Другие языки (например, Rust) потребовали бы фундаментального переосмысления управления памятью, мутации данных и общей архитектуры, что не соответствовало цели порта с сохранением существующего поведения.

🫥 Cross Join
⠀

Один из сильнейших страхов многих программистов (и не только) - страх показаться невежественным или тупым, страх задать глупый / очевидный вопрос. Высказать мысль, в которой не уверен. Но иногда это просто необходимо делать.

Если что-то не понял - лучше спросить сразу. Будет намного глупее сделать что-то не то, просто потому, что не уточнил какие-то моменты. Применить неверный подход, не посоветовавшись с человеком, который в теме. Плохой результат подсветит тупизну намного ярче, чем "сорян за тупой вопрос, но почему бла-бла..."

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

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

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

Фух, полегчало. А то, когда на канале стало несколько тысяч подписчиков, я начал ощущать некое внутреннее давление. Что не дай бог скажу что-то не то. ЧЗХ. Идите нахуй короче, я точно также ничего не знаю, как и вы.

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

Если не рассматривать Хабр, где в комментариях люди соревнуются в крутости и токсичности, а реальную жизнь, то выясняется, что люди, которые не боятся говорить и спрашивать как думают, намного более симпатичны, и с ними легче работать в команде, их больше уважают. Больше тупых вопросов - больше уважения :)

Получать информацию намного круче, чем скрывать свою неинформированность

🫥 Cross Join
⠀

Крошка джун к лиду пришел, и спросила кроха
что такое хорошо, и что такое плохо

Лид ответил, не тая
Всё айти - одна херня

Джава память всю сожрёт,
Еле-еле стартанёт

Го придуман для тупых
Скала, Хаскель - для больных

Асм пойдёт задроту-гику
Rust - отрада контрол фрика

PHP оставим деду,
Пусть там выпьет за победу,
Типа сайтов громадьё
(но на деле всё старьё)

Скрам говно, фронтенд говно,
Уведут проект на дно

Чтоб понять Апаче Кафку,
Почитайте Франца Кафку

Только клод - моя подмога,
Жаль, что ёбнутый немного.

Лид - давно не разработчик
Жалкий таскообработчик:
Претворяется спецом,
Сделав умное лицо

Все владельцы самодуры
А эйчары часто дуры

Каждый долбаный админ
В мыслях тёмный властелин

Проджект менеджер к чему
Непонятно никому

Остальным одна забота:
Делать видимость работы

А хорошего в айти
Адеквату не найти

(С) 🫥 Cross Join
⠀

В последнее время всё чаще слышу "как вы живёте в Go без фреймворков, это же неэффективно"

Ну блин, а зачем он нужен? Если пишешь типичный микросервис, REST + кафка, например:

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

Роутинг http-запросов есть в стандартной либе, если надо какие-то расширенные возможности, полезные мидлвары и т.д - юзаешь либу chi или аналог

Логгер прекрасный встроен из коробки (json, уровни логирования и т.д).

Ну кафка да, подключаешь либу.

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

Валидация данных делается с помощью либы.

ORM в мире Go редко используется, но если прям надо, ну подключи gorm

Всякие там dependency injection системы в микросервисах вообще не нужны, но если код сервиса разрастётся, то можно потом прикрутить либу (uber-go/fx, например)

Метрики для прометея - либу взять, прикрутить не сложно. Она сразу выдаёт параметры самого рантайма (количество горутин, памяти и т.д), а свои кастомные тоже прикручиваются не особо сложно, например в мидлвару запихать.

Профайлер в Go приделывается парой строк кода

Подход "convention over configuration", которые так любят фреймворки, считаю ошибкой. Когда тебе создаётся 100500 папок, в которые надо что-то сунуть в нужные места (которые надо знать наизусть), всё вокруг отнаследовано от неведомых классов, которые тоже надо знать. А прикрутить что-то стороннее/нестандартное внутрь этого монстра - задача со звёздочкой.

Мне, короче, больше нравится парадигма "Явное лучше неявного".

Фреймворки лучше подходят для задач "сделай сайт целиком", с авторизацией, сессиями, шаблонами и т.д, но это не является типичным юзкейсом языка Go

🫥 Cross Join
⠀

Компания Wiz Research обнаружила критические уязвимости в Ingress NGINX Controller для Kubernetes, названные #IngressNightmare. Эксплуатация этих уязвимостей позволяет злоумышленникам получить неавторизованный доступ ко всем секретам в кластере Kubernetes, что может привести к полному захвату кластера. Около 43% облачных сред уязвимы к этим атакам.

https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

🫥 Cross Join
⠀

Начиная с Chrome 135 появилась возможность кастомизировать <SELECT> элементы. Туда можно пихать иконки, применять различные стили и т.д.

https://developer.chrome.com/blog/a-customizable-select


🫥 Cross Join
⠀

Go планирует улучшить производительность в контейнерах (proposal)

GOMAXPROCS - это настройка в Go, которая определяет максимальное количество CPU-ядер, используемых для выполнения горутин параллельно.

В Go 1.25 разработчики предлагают встроить умный GOMAXPROCS, который будет учитывать ограничения контейнера (cgroup).

Сейчас Go автоматически устанавливает GOMAXPROCS равным всем логическим ядрам на машине, что создаёт проблемы в контейнерах, где доступно меньше ресурсов. Это приводит к неэффективной работе, проблемам с производительностью и троттлингу приложения.

Проблема актуальна для всех, кто запускает Go-приложения в контейнерах (Docker, Kubernetes), и остро стоит в окружениях, где на одной машине запускается много контейнеров с ограниченными ресурсами.

Сейчас разработчики решают эту проблему ручной настройкой через переменные окружения или используя библиотеку от убера. Новое предложение добавляет в сам Go автоматическое определение ограничений CPU из cgroups и динамическое обновление GOMAXPROCS при изменении этих ограничений.

🫥 Cross Join
⠀
#golang #performance #kubernetes #docker

Самое большое зло на свете - это неявное приведение типов.

Вот мои любимые приколы:

$str1 = "240610708";
$str2 = "QNKCDZO";

echo md5($str1) . "\n"; // 0e462097431906509019562988736854
echo md5($str2) . "\n"; // 0e830400451993494058024219903391

if (md5($str1) == md5($str2)) {
    echo "MD5 хеши равны!\n";
} 

md5 хэши равны, потому что php думает, что 0e... - это экспоненциальная нотация числа.

Дальше необъяснимое, прибавлять единицу можно по-разному, получая совершенно разный результат:
`

$x = "0abc";
$x = $x+1;
echo $x; // получится 1

$x = "0abc";
$x++;
echo $x; // получится строка 0abd

Не только в php проблемы, конечно.

На картинке выше, если кто не понял, Excel приводит 1/2 к 1 февраля.

Ну и классика js

name = 2;
console.log(name+2); // 22

потому что window.name хоть и получило число, но это заголовок окна, т.е. костылём прибито, что это строка.


Или такое

[1, 2, 3] + [4, 5, 6]  // -> '1,2,34,5,6'

Because fuck you, that's why.

Короче, не говорите мне, что неявная типизация - это удобно. Это говно

🫥 Cross Join
⠀
P.S. В коментах пишут про ===, strict types. Но ребят, это как раз попытка языков уйти от неявного приведения типов, потому что это говно.

Ох уж этот вайб кодинг. Https или api 🤦

🫥 Cross Join
⠀

encoding/json/v2 будет внедрен в go1.25 под экспериментальным флагом: https://github.com/golang/go/issues/71845

Анмаршалинг будет работать намного быстрее, кроме того, в новый json добавили 100500 фичей. nil-слайсы будут маршалиться как [], можно задать формат для времени, указать case-sensitive или нет и много других штук.

Соответственно, v1 и v2 несовместимы, очевидно не получится просто добавить везде v2 и катить в прод. Старый json обещают поддерживать вечно

🫥 Cross Join
⠀

Кирилл написал пост, что ИИ не заменит программистов.

Да, блин, точно заменит. Не нынешними технологиями, а чуть позже.

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

Машина не сразу, но победила, перебором ходов и заучиванием дебютов.

Потом говорили, что даже не то, что человек, а какая-нибудь жалкая мышь мгновенно и запросто распознаёт объекты, а компьютерное зрение это делает долго и с низкой точностью

Не сразу, но машина победила, и стала намного быстрее и точнее, чем живые существа.

Потом говорили, что в игру Го машина не может победить, потому что там подсчет ходов вообще не имеет смысла, только на интуиции. А человек - гений интуиции.

Результат немного предсказуем, в Го машина тоже побеждает. И алгоритм приспособили под любую вообще подобную игру.

Говорили, что все эти системы узко натренированы на что-то, но... вот щас оказывается, что машина, натренированная на тексты, может прям очень много дохуя.

Говорили, что не может программировать, рисовать и т.д, это невозможно, человеческий гений бла бла бла

Машина начала программировать, рисовать, писать тексты и стихи. Да, местами фигово, но, как говорится, "мы находимся здесь"

Самое интересное, что GPT задумывался как T9 на максималках, и никто не ожидал, что она сможет программировать и переводить с французского на китайский, учитывая контекст.

Кстати, раньше смеялись над автоматическими переводами ("охлади траханье, углепластик"). Сейчас запускаются международные стартапы вообще без присутствия человеческого переводчика, всё переводится чатом гпт. Ну, максимум, кто-то вычитывает в особо важных ситуациях. Переводчиков заменили на 99%.

Еще там что-то говорили про то, что мозг человека содержит 100 млрд нейронов. Но современный комп, например, Macbook M4 содержит 30 млрд транзисторов. Конечно, сложно сравнивать нейроны и транзисторы, но блин.

И рост продолжается, становится больше ядер, компьютеры объединяются в облака и т.д.

Тупо оценивать будущее, опираясь на сегодняшние возможности. Copilot 1.5-2 года назад был скорее анекдотом, сейчас для большинства разработчиков - это незаменимый инструмент. Да, надо перепроверять, да он не может поговорить с коллегами и уточнить задачу, но блин.

И каждый раз одно и то же, "компьютер никогда не сможет...".

Единственная надежда на то, что тупо не хватит энергии на все задачи. Уже сейчас это заметная доля потребления человечества, при том, что многие даже не начали толком пользоваться.

🫥 Cross Join
⠀