Вынесу из комментов

Про стахановский труд:
дать по башке месному начальству и улучшить свои условия труда. Все болезни от нервов и кому нужен молодой инвалид

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

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

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

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

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

Анализ синих экранов смерти

После того, как я поменял мониторы, начался странный трабл - основной домашний комп, оставшийся со старым монитором начал падать в синий экран смерти регулярно. Причем даже не показывая его - а мгновенно перезагружаясь.
Код ошибки 1000007F, первый параметр 8 - т.е. double fault. Ошибка поверх ошибки - мгновенная смерть :)
Сначала разбираться мне было лень, а сегодня после очередного падения решил осмыслить что это такое. Пошарил по гуглу и набрел на полезную ссылочку. Тулса по ссылке является оболочкой для запуска Windows debugging tools для анализа мемори дампа от падения. Почитав треды на том форуме, понял что это именно то что надо.
Скачал. Дебаггинг тулсы у меня уже стояли - я ими искал баги в своем коде, подгруженном в IIS или Firebird. Запустил анализ минидампа памяти от синего окна. Дебаггинг тулсы сразу полезли массово качать отладочную информацию с микрософта (никак не предупреждая, так что сидящие на дорогом трафике могут попасть, хотя там всего пару десятков мег).

Вывело это дело список модулей и трейс стека. В трейсе стека явно видно прохождение вызова от отрисовки текста, через драйвера терминальной сессии, до TCP стека, с перехватом по дороге фильтрами файрволлов и прочего наставленного тут сетевого софта, до драйвера nat от прокси-сервера, после которого идет nt!DbgPrint, внутри которого еще четыре уровня вызовов, на последнем и сидит BSOD (А ПОД КАМУШКОМ - РАЧОК-С!!!) :)
А надо сказать что на этот комп после замены монитора я начал ходить в основном через терминальный сервер - у него остался для загрузки старый моник 800х600, но основная работа ведется с нового моника подключенного к ноутбуку, на котором открыто окно терминальной сессии. И если так не ходить - то и комп не падает.
Т.е. все указывает на какой-то невнятный конфликт между терминальным сервером и драйвером nat, который проявился только сейчас. Прекращу временно эту практику сидения в терминальной сессии и посмотрю что выйдет. А потом заменю моник на нормальный и буду сидеть за тремя мониторами на столе :)

Все таки синие экраны смерти и дампы памяти от них несут, как оказалось, множество полезной инфы :)

И еще про отладчики

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

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