Саня Технадзор 🦾

Какие затейники. Хотя я уверен что пойдет — для удержания и направления потока трудовой энергии инструмент очень полезный, это вам не скрины скриншотить. У Амазона же пошло, и никто амазон на вилы не поднимает в сети. Который год. Пошумели как-то и забыли. Зато там автоматические увольнения, все цифровизовано!

Ранее два разработчика из Индии Кушал и Вивиан представили ИИ-систему для контроля работников на потогонных фабриках, чтобы сделать их эффективнее на 105% и более при должном принуждении и слежке. Нейросеть проекта Optifye.аi с помощью камер 24/7 анализирует труд людей на каждом конвейере и выводит KPI каждого человека и команды. Если их показатели низкие, то оператор может накричать на сотрудника или применить дополнительные меры. Пользователи в отзывах не оценили проект. Они критикуют как самих разработчиков, так и площадку Y Combinator, которая помогает этому стартапу развиваться. На видео показано, как соучредитель Optifye Кушал Мохта, выступающий в роли начальника швейной фабрики, звонит руководителю, а на самом деле своему соучредителю Вивану Байду, по поводу неэффективного работника, которого называет «Номер 17». «Эй, Номер 17, что происходит, мужик? Ты в минусе», — спрашивает Байд рабочего, который отвечает, что он работал весь день. «Работаешь весь день? Ты ни разу не достиг своей почасовой производительности, а твоя эффективность составила 11,4%. Это очень плохо», — парирует Байд. Проверив панель инструментов Optifye, руководитель смотрит на производительность «Номера 17» за 15 дней, решает, что работник работает неэффективно, и выносит ему штраф. После критики в Сети по поводу использования ИИ для улучшения возможностей рабовладельцев Кушал и Вивиан начали удалять свои аккаунты.

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

Как приручить икрана дракона. На первый взгляд может показаться, что это типичный ответ от очередной шайтан-машины, каких полно. Но тот, кто в теме, а особенно разбирается в Rails, понимает: даже самые модные новинки пишут безвозвратно отвратительный, испорченный код уже на вторую-третью серьёзную итерацию — это когда мы ставим перед ним настоящую боевую задачу, типа "обжектив". Уважаемый робот довольно спокойно настраивается на понимание того, как тебя понимать и в чём помогать. Изначально такие машины выдают простыни шизоидного кода уровня джунов, которым внезапно разрешили писать много примерно работающего кода — и сразу. Пока эта шайтан-машина не освоит полный цикл запуска тестов, их проверки и дописывания кода, её нельзя считать разработчиком. Она пишет то, чего не существует, теряет переменные, иногда их переименовывает. На данный момент я выработал подход, как держать её в тонусе адекватности. Сразу скажу: скармливать весь код в каждом запросе, как советуют некоторые, — это только хуже и дольше. Разбирать её простыни вы устанете. Но с ней можно договориться. Если слегка подготовиться, принять определённые принципы написания кода и проектирования продукта в целом, то у вас начинает появляться то, что в будущем можно будет назвать "спелись". Пока до этого далеко, но с циклом обратной связи уже стало намного лучше. В направлении цели мы начали двигаться вместе, а не только я один. Самое главное — я воспринимаю LLM как часть нашей новой общей операционной системы: - CPU теперь — это LLM, - байты — это токены, - оперативка — это размер контекстного окна. И решения я применяю в контексте, независимом от конкретной LLM. Да, есть минимальные требования. Например, я бросил все эксперименты с локальными "ламами", потому что это просто ерунда. Время и деньги всё равно тратятся, но главное — время. А работает это очень плохо. Хорошие LLM через API — другое дело, они работают шикарно, и с ними намного проще. LLM как процессор: захотели — поменяли. И то, что ты запускаешь, запускается и делается быстрее и умнее. Так что адаптация путеводителя руководителя до звания путеводиля AI руководителя идет полным ходом. Что-то интересное точно грядёт.

Полирнем серию практических постов темой Найма.  Я не верю в найм. Точнее, я не верю в собеседования. Нет, иногда мы можем проверить какие-то т.н. hard-скиллы: дать программисту тест, провести экзамен бухгалтеру, проверить теоретические знания менеджера. Однако, ценим мы и платим больше всего людям за т.н. soft-skills: ответственность, стрессоустойчивость, способность работать в команде, и так далее. И есть только один софт-скилл, который мы можем проверить на собеседовании - это умение себя продавать, который часто конфликтует с другим полезным качеством: честность.  И зачем тогда все эти сложные механики и раунды собеседований? Я перед тем как основать QSOFT пытался устроиться на работу менеджером в Студию Лебедева, 4 собеседования прошел, 2 недели к ним ездил. Не взяли. Замечательный процесс, очень «полезный». Есть еще одна фишка. По моим наблюдениям, самые лучшие люди всегда себя немного недооценивают и скромничают. Они всегда считают, что могли бы быть лучше (собственно, поэтому они лучшими и становятся). Ты его спрашиваешь на собеседовании: «А вы говорите на английском? - он отвечает: «Нет». А потом выясняется, что у него лучший язык во всем коллективе, просто ему самому кажется, что «это же разве говорю, так просто изъясняюсь» (английский, если что, взят для примера).  Я верю, что на собеседованиях надо брать почти всех. Какой-то базовый фильтр на навыки, на уровень - и дальше не умничать и не строить из себя оракулов. Но! Я считаю, что испытательный срок не должен быть формальностью. Что людей надо оценивать не по собеседованиям, а по работе и результатам испытательного срока, и реальное решение принимать уже там: продолжать или расставаться.  Хотите сразу хорошего и сильного? Пожалуйста, есть хантинг. Но там свои приколы. А если вы разместили объявление на ХХ и пригласили человека на собеседование, пожалуйста, оценивайте свои телепатические способности скромнее. 

ПродА/Укт менеджеры - это предприниматели которых набирают по объявлениям. И потом жалуются.

Что с заказной разработкой Мысли вслух. Все причастные давно страдали от ситуации, когда ругались на клиентов за их "необразованность". Время и устойчивое проникновение технических систем показывают, что сейчас можно чётко понимать результаты жизненного кастдева — то есть кому на самом деле и какой продукт не просто нужен, а ещё и будет им усвоен. Так вот, кастомная разработка — это шикарный инструмент, дающий огромные перспективы: возможность занять место на рынке буквально из ничего, двигаться вперёд, закреплять текущее положение и не зависеть только от людей, масштабироваться куда душе огодно и тд. В общем и целом там килотонны добавленной ценности на квадратный миллиметр. Но есть нюанс. Не каждый исполнитель способен выдавать результативную кастомную разработку, которая приведёт к значимым высотам. Мысль заключается в том, что GPT показывает, как разделяется рынок потребления — и как он фокусируется. Кастомная разработка, на самом деле делающая типовые решения это своего рода "бигмачная", как раз и является этим самым GPT. Где-то вокруг этой кухни выстраивается очередь из курьеров. Эти курьеры, в свою очередь, работают на какую-то компанию, которая организует их работу. Но при этом существуют и другие сети, и самостоятельные рестораны, и столовые, и домашняя кухня. А есть рестораны, куда записываются за год вперёд. В каждом из этих форматов свои правила организации труда, своя система производства и логистики в ответ на поступающие заказы. На каждом этапе своя квалификация специалистов и свои требования, продиктованные системой разделения труда. Требования к зажариванию булки в микро-жарке по таймеру — это процедура, требующая минимальной квалификации. Основное требование в таких предприятиях — строгость следования дисциплине. В ресторанах высокой кухни требования будут совсем другие. Думаю, понятно. Но вернёмся к клиентам. Учитывая всё это разнообразие, становится предельно ясно, что клиент кастомной разработки должен обладать "хваталками", чтобы получить и усвоить то, что кастомные разработчики могут предложить. Но дело не только в "хваталках", но и в "выдавалках". Здесь я тонко намекаю на форму, структуру и детализацию, максимально привязанную к реальности, но при этом способную совершать серьёзные прорывы (это я так изобразил инновацию). Уберизация, коммодизация и GPT-изация складывания котлет между булок в каждом отдельно взятом случае просто акцентируют и фокусируют усилия кастомной разработки на детализации и силе идей, которые она может предложить тем, у кого есть "хваталки". Выдавалки — это отсылка к пониманию и проблематизации решаемых задач. Те, кто знаком с ТРИЗ, могут не только выделить задачу, но и предложить её решение, приводящее к росту потока полезности. Хваталки — это отсылка к внутренним ресурсам и организационным возможностям, но в первую очередь к волевым и лидерским качествам, позволяющим применять инновационные решения, исходя из собственного видения картины мира и места своего предприятия в нём.

Я медленно снимаю санкциии ... К сегодняшним событиям и новостям, делюсь своим важным мнением: Если всё идёт как в сказке, то, я думаю, наши будут запускать сервисы не просто так, а с приземлением — как это совершенно спокойно делают в Китае или Европе. Но что-то мне подсказывает, что это очень сладкая наживка, которую мы пока не можем рассмотреть, и кидок будет мягкий, но очень дальний и сильный. Если, конечно, мы не разберёмся, в чём тут дело. Приведу один очевидный аргумент: все заметили, как при Трампе весь оркестр заиграл в другой тональности. Ровно так же, после Трампа, он сможет заиграть в совершенно иной. Те самые "передышки для набора ресурсов" по косвенным признакам выглядят примерно так. По мелочи, да, какие-то сервисы можно будет поюзать. Думаю, даже стратегически им важно, чтобы мы сливали свои данные в их GPT, и этот момент они держат под контролем.

Нужен ли нам ТРИЗ? Жаркий тредик о ненужности собеседований очевидным образом уперся в ТРИЗ, с утверждениями, что разработчики не занимаются снятием технических противоречий и что это ложное утверждение. Оставим добычу фактов о ложности постулатов ТРИЗ на совести трудящихся, я же дам подтверждение — абсолютно согласен, что большинство разработчиков сознательно не занято снятием технических противоречий в своей работе. Ответ будет ниже, но начнем, конечно, с того, как ЖоПэТэ будет всех заменять. Ну не приемлют разработчики тот факт, что их работа, точнее, полезность производной их труда — это очень точно замеряемая вещь, в деньгах и в полезности. Просто не все системы разделения труда (организация и производительность труда в каждой компании) еще подоспели. Долгое время они развивались вширь, а не вглубь. Сейчас пошло углубление. Раскрою секрет, который ожидает разработчиков в ближайшем будущем: оценка эффективности решений согласно их стоимости будет наглядно демонстрируема в моменте. Токенизация LLM-рантайма подвела к такой ситуации, что за выполнение каждой функции стоят конкретные деньги. Это просто сумма за каждый вызов, считаемая через токены. Неимоверными темпами мы подходим к тому, что эффективность и результативность созданных решений, решающих конкретную задачу, будут так или иначе измеряться в деньгах напрямую. Если когда-то у меня это были влажные фантазии о том, что поэлементно полезную сложность решения можно выражать в деньгах, через стоимостные эталоны конкретных индивидов на местах, получая при этом прогнозируемую конвертацию денег в полезную программу, то на данный момент уже вызов функций в LLM идет как обращение и стоит денег. Неважно, заказываете ли вы это через API или платите за свою стойку GPU сами. В случае самостоятельной аренды добавляется фактическая стоимость простоя. Вот вам и техническое противоречие, лежащее в основе, которое требуется постоянно устранять для развития и эксплуатации системы: при увеличении полезной нагрузки (данными и вызовами) стоимость возрастает. Пример задачи из жизни, сильно упрощенный:

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

Пути решения: - Выдавать все теги в промте контекста запроса при вызове на каждый текст, а затем сохранять совпадающие, это увеличит промт и количество токенов на вход. - Делать вызов существующих категорий и спрашивать, есть ли каждая категория в этом тексте. Это увеличит количество вызовов к АПИ gpt. - Запрашивать все категории вообще, выбирать найденные у LLM и отмечать совпадающие. Вариантов можно привести массу, но при этом можно поставить элементарную задачу, указав на противоречие: Стабилизировать разметку текстов в LLM минимальными затратами. Можно сказать, что это "очевидно", но очевидным (то есть "очами видно") это стало только после того, как я расписал детали. А подходить к вопросу — задача это или не задача — нужно именно с точки зрения выявления базового технического противоречия, которое и нужно устранять. Большинство известных мне разработчиков работает в режиме исполнения хотелок и никогда не проявят себя, чтобы указать, что "задача — это не задача". Они принимают мир так, как есть: взяли под козырек — и погнали пилить. При поиске нужности и полезности задач именно через методы ТРИЗ выясняется, что огромное количество дел не надо было делать. Поэтому у нас растет энтропия: разрастается количество ненужных систем, интерфейсов, появляется ненужная сложность. Ключи к этому есть, и они известны. Будем посмотреть, куда все придет, изучайте ТРИЗ — пригодится каждому.

Жаркая тема, тогда еще накину. По ссылке вы увидите очередное обсуждение темы, там уже про литкодинг на собесах Яндекса. https://t.me/decembristit/2573 И как говорят, что Яндекс начал давать "реальные задачи", и приводят пример, как дают эту "реальную задачу". Но вот ситуация — просят переписать функцию, что-то там поправить и т. д. Я об этом и говорю — это не реальная задача, а какой-то кусок внутреннего процесса чьего-то решения какой-то задачи. Усвойте разницу. Результатом по задачам всегда является компонент. К какой бы специфике деятельности вы это ни применили. Компонент — это что-то, что можно использовать в деле, в деятельности компании. Внутри, снаружи — неважно. Так вот, организация труда по разработке любого продукта разбивается так, что единицей результата должен быть полезный (КОМУ-ТО) компонент. Там на скринах про "реальные задачи" говорят править функции. Господа присяжные заседатели, задача на функцию — это микроменеджмент. Очень многие техлиды ищут ответ на вопрос, до какого уровня надо декомпозировать. Ответ простой — до уровня предметки и интерфейсов приема предметных данных. Все что глубже — это специфика. А уже обратное работает — да, функция может по форме совпасть с компонентом результата. Но не наоборот! Проще объяснить на примере варки супа. Вот шеф берет к себе на работу человека, и ему нужно, чтобы он блюда готовил. Да, они время от времени делают заготовки, но это как часть дисциплины внутри, и она ситуативная. Один человек — одно блюдо. Это ответственность, наказание и поощрение за блюдо. Блюдо — это то, что едят, как гости, так и на кухне. И вот текущие собеседования — это разговоры не о блюдах, а о том, какие способы чистки морковки и картошки бывают. Можно ножом, можно какой-то машиной, можно такой хитрой штукой, которая соскребает быстро, и т. д. А в итоге работать надо будет — супы варить. И окей, тестовое задание на скринах с функцией — это как взять и попросить человека почистить морковку, и на основании этого дать ему оффер. На работу, где выясняется, что варить супы он не может. Аналогия натянутая, но она показывает ситуацию с часть-целым и полное отсутствие понимания того, что люди на работах делают, в чем их реальная работа. Но и они все находятся в каком-то лютейшем "потоке ценности для клиентов". Прозрите, дорогие мои, и будет вам счастье!

Давайте запечатаем саркофаг с мотивацией собеседующих. Как вы знаете, я придерживаюсь, применяю и настаиваю на целеориентированной деятельности везде, где только могу дотянуться. Или же, иначе говоря, на делократии. Когда я взаимодействую с коллективами в рамках проектов, учитывая, что и я, и они нацелены на результат, наша совместная работа автоматически становится целеориентированной. Но при этом все те процедуры и «танцы с бубнами», которые устраивают команды, становятся препятствием на пути к результату — как по времени, так и по сути. А теперь пример на стыке двух тем: делократия и собеседования. Как я уже говорил, при действующей делократии собеседовать человека в принципе бессмысленно. Первый шаг, который демонстрирует квалификацию, — это запрос на составление плана получения результата по выданной задаче. Если человек разбирается в деле, то есть является специалистом, он составляет этот план за три минуты. План получения результата — это перечень компонентов и последовательность их изготовления, получения, закупки и монтажа (мерджа и деплоя). Если нет, вы услышите все известные и неизвестные слова из Agile-словаря, которые Греф транслировал на всю страну. Принять их вам эти слова нужно, потому что «у нас так принято». Но как получается, что у кого-то это «так принято», если это чушь собачья и не имеет отношения к результату? Вы спрашиваете — я отвечаю пруфом, ссылкой. Теперь добавим к ситуации «демократизацию» принятия решений и поясним еще раз. В делократии целеориентированность подразумевает дерево ответственных лиц, привязанное к их конкретным целям. Если человеку в команде нужен коллега, он сам принимает решение — нужен тот или нет. Демократизация же снимает ответственность с одного человека, размазывая ее на коллектив. Этому размазыванию нужна оправдательная база, и люди начинают тащить «лучшие практики». Вместо того чтобы просто взять человека, взять за это действие ответственность (что этот человек будет что-то уметь делать), дать ему задание (взять ответственность за требования и свое целеполагание) и получить результат, мы получаем целую линейку безответственности. Чтобы это не выглядело совсем как идеократия (бессмыслица), все эти коллективы устраиваются по принципам, описанным выше, — по дикарским законам доминирования. Но так как сейчас нельзя просто убить коллегу, иерархия в коллективе формируется через проявление доминантности. Умничать и выглядеть «начитаннее, умнее», а значит, доминировать, у программистов принято через «лучшие практики» и языки программирования. Haskell и прочие «интересные вещи» — прекрасный пример таких доминантных войн. Хотя я не вижу, чтобы мир рушился и переставал развиваться без Haskell. Возможно, у него есть техническое применение, но его главное назначение — это борьба за доминирование. Ровно по этой схеме, если коллектив оставить на самоуправление, через какое-то время мы получим ту жесть, что описана выше. Связано ли это с результатами? Нет, никак.

Собеседования в Яндексе: Скандалы, Интриги, Расследования! "Чем большая отдача нужна, тем сложнее ритуал инициации". Тепленькая пошла, не зря мы тут с Ильей Николаичем зарубы устраиваем, вытряхивая правду матку внаружу:

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

В это время, где-то в Яндексе:

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

и

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

Все мы знаем, что Яндекс — замечательная компания, но вот мы получаем еще и подтверждение этого напрямую. Один из моих бывших сотрудников в далеких десятых, после работы у меня, устроился в Яндекс. Тогда такого там еще не было, но какая-то группировка вокруг Ильи Сегаловича уже проявлялась — фамилии называть не будем. Эта группа сильно повлияла на мышление Ильи. Насколько мне известно, он был добрым и идеалистичным человеком. Но, как показывают события, борьба «башен» Яндекса и различных группировок все равно выходит наружу. Сейчас, как я понимаю, одна из групп хорошо обосновалась и уже достаточно открыто укрепляет свои позиции. Часть успешно переехала в Израиль. Те, кто не смог, остались здесь. Кто есть кто — я не знаю, передаю, что слышал. Сейчас мой бывший сотрудник находится в Израиле, но со мной общается не слишком охотно — хотя это уже совсем другая история. Ничего не подумайте, он уехал задолго до сегодняшних событий, но, тем не менее.

Ситуация следующая

Внедрение — это вам не просто так. Внедрением нужно заниматься! Случился интересный диалог. Я давно накапливаю в заметках фактуру по внедрению, и вот этот диалог хорошо продвигает весь этот массив материалов от задумки к публикации. Тема сложная в донесении, но крайне важная для всех участников сложных проектов. Успех всех запусков в B2B зависит не от продукта*, а от его внедрения — это та самая последняя миля. * Разумеется — наличие продукта который работает и решает задачи это необсуждаемое минимальное условие, но не всегда ) Если вы не чувствуете этот момент и слишком разогнались (как я раньше, как и многие) — прочитайте внимательно. Это основная мысль, черновик. Когда-то сделаю ролик и гайд, но потом. А пока что зафиксирую реплики: Тема: почему не запускаете свой стартап, что вам мешает? Реплика_1:

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

Мой ответ: Когда я пытался внедрить свою чудесную систему на производство (система, объединяющая несколько производств в одно по целям, потокам дел и результатам), произошло то же самое. Работал с заводом в рамках СПБ Технопарка. Я там ошивался, офис у меня был в соседнем здании. Суть такова: владелец этих предприятий загорелся моим проектом, но через два дня пришел и сказал крамолу:

Всё супер, проблема решается огромная (хаос пяти КБ и разрозненных проектов), пойдет отлично. НО. Допустим, мы начали пилот. Это значит, что для успешного результата мне нужно будет как минимум из каждого КБ оттянуть по одному человеку на этот пилот. При этом он (человек) не будет выполнять свою основную работу или будет делать её медленнее, что практически равноценно бездействию. Голдрата читал? Вот и отлично. У меня сразу образуется цепочка простоев. А если простой — это как автомобильная пробка, — все резко начинают тормозить по цепочке. Разогнать процессы потом будет дольше и сложнее (плюс пострадает синхронизация дел и рабочих продуктов). А у меня там еще и свой хаос. Внедрение чего угодно в производство стоит вдвое дороже: первый раз ты платишь за простой специалистов, второй — ты не зарабатываешь, пока специалист выпадает из цепочки. В общем, вывод: чтобы внедрять твою чудо-систему, даже бесплатно, мне самому придется за это заплатить, рискуя срывом собственных процессов. При этом заплатить дважды и взять риск что я на своем участке не справлюсь, а я это предполагаю.

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

Всем замечательной и продуктивной рабочей недели!

Обама Саня Doge ТехНадзор! Обращаю внимание: это идеальный пример внедрения делократии. В миссию вставлено дело — чеки. Все, это невозможно оспаривать. Юрист Том Ренц, изучая указ Трампа о DOGE с целью выявления его незаконности, обнаружил, что он безупречен. Оказалось, что Трамп и Маск ничего не создавали. Это сделал Обама! В 2014 году Обама создал Службу цифровых технологий США (USDS). Она была задумана как бюрократическое исправление после провала запуска веб-сайта Obamacare. Переносимся в 2025 год. Трамп переименовывает её в DOGE (Служба DOGE США). Он сохраняет аббревиатуру, сохраняет финансирование, но даёт ей совершенно новую миссию: "Найти чеки". С юридической точки зрения DOGE неуязвима, поскольку уже была полностью профинансирована и функционировала. Трамп использует 5 USC 3161, что позволяет ему создавать временные кадровые органы. Команды DOGE встраиваются практически в каждое федеральное агентство. Каждая команда состоит из юриста, кадрового специалиста, молодого технического специалиста (зумер-ботаника) и следователя. Они подчиняются DOGE, а не агентству, в которое встроены! Но это ещё не всё! Трамп использует 44 USC, Глава 35, регулирующий федеральные IT и кибербезопасность. Поскольку USDS изначально был органом IT-надзора, DOGE теперь имеет полный доступ ко всем федеральным информационным системам. Его указ составлен так, чтобы блокировать юридические оспаривания. Включает формулировки, которые аннулируют конфликтующие указы. Приказывает каждому агентству подчиняться. Отказ означает нарушение президентской власти. Конгресс не может урезать финансирование. Минюст не может подать в суд за превышение полномочий. И только демы продолжают стучаться лбом о бетонную стену. Обама буквально построил идеальную теневую (хоть и государственную) IT-бекдор. Трамп и Маск просто взломали систему и захватили административные полномочия. Теперь Маск имеет юридический надзор за внутренними системами всех крупных агентств. Административное государство не может этому помешать без переписывания множества федеральных законов. Они обошли систему, и никто ничего не может с этим сделать. Обама — создатель DOGE! Разве это не прекрасно?

Писал человеку комментарий, а получился ответ для многих.

Я уже 45 дней без нормальной работы, стресс берёт верх, может кто помочь?

У меня в планах был эфир про деньги, но, видимо, перенесу его поближе. Суть проста: вся текущая система работы — от процесса найма до распределения результатов — построена так, чтобы выбить любые попытки думать и говорить о деньгах. Я давно замечал это, но не мог понять, как именно оно реализовано и где точка опоры, за которую можно зацепиться. Теперь ясно: вся эта мутная вода и непонимание, куда движутся результаты, создаются не ленивыми разработчиками и бесконечными JS-фреймворками. Это идет от недобросовестных работодателей и обслуживающей их клики. Просто их большинство. Их цель — чтобы человек не мог явно предъявить результат. Потому что понятный результат и измеримая польза, определяемые не менеджером или «старшим», а делом и фактом, создают неудобный вопрос: как распределяются финансовые поощрения? А это та самая грань, за которую никого не пускают. В результате возникает мутная, размытая система: создается иллюзия, что все работают, что-то делают, куда-то двигаются. И это выгодно всей верхушке. Главный инструмент контроля — финансовая неуверенность Исполнителю намеренно создают слабую позицию в вопросах денег. Если человек боится спросить о деньгах, боится обозначить свою ценность, если его можно зашугать или просто не взять на работу — система остается устойчивой. Привет, реальность. Есть ли выход? Да, и он начинается с внутреннего состояния. В первую очередь — стрессу тут не место. Пусть рушатся иллюзии, пусть становится видно, кто на самом деле играет против тебя. Это хорошо. Запомни: внешние обстоятельства ты почти никогда не контролируешь. Но у тебя есть внутренняя опора и стержень. Если ты сам же будешь топтать свой стержень, не доверять своей чуйке, то кто вместо тебя сделает твою жизнь лучше? Главное правило — не разрушай себя Мир полон людей, которые готовы: — смешать тебя с дерьмом, — сказать, что ты нескиловый, — отказать без причины, — кинуть на деньги. И сейчас маски слетают со сверхзвуковой скоростью. Но не становись своим же врагом. Порадуй себя чем угодно. Ты — это то, что у тебя есть. Если проходишь сквозь ад — просто иди. Не останавливайся.

Лайк, шер, алишер https://youtu.be/Hy0aA5o8bjk

Бессмысленность и беспощадность проведения интервью выходит на свою закономерную траекторию. По ссылке клонируете себе проект и запускаете. 1. Создаёте интервью, задаёте тему собеседования промтом. 2. Загружаете PDF-резюме кандидата. 3. Указываете количество (!) вопросов, например 5, задаёте время, например 10 минут. 4. Корректируете созданные вопросы. 5. Выбираете голос интервьюера. 6. Кидаете ссылку кандидатам — они говорят с роботом. 7. Получаете репорт и саммари. Вместо того чтобы дать человеку тикет (рабочую задачу из вашего Битрикса) и сразу получить решение, которое показывает его профпригодность, устраиваются танцы с бубном. А в итоге человек всё равно приходит и делает задачу из трекера — может он, либо не может с вами работать выясняется вне зависимости от интервью, сюрприз — в работе! Почему так не делают — потому что дать задачу из трекера, и неважно, программистам или кому-то ещё, могут не только лишь все. Оказывается, что весь полезный труд в компании должен как-то разделяться, с каким-то разумным планированием, на какие-то детерминированные кусочки результатов (даже НИОКРы прекрасно делятся на чёткие части). Все для того, чтобы этот труд можно было кому-то передать, понимать его границы и результат, да так, чтобы этот результат пригодился в общем деле и мог быть в него смонтирован. Тут выводов нет, просто риторические вопросы: 1. Если не могут выдать задачу кандидату, думаете, в компании дальше смогут выдавать нормальные задачи, которые понятно как делать, и которые потом спокойно примут и скажут спасибо? 2. Даже если задачи кривые и управление отсутствует, но зачем-то нанимают людей — тогда зачем вообще проводить интервью, если самим не понятно, куда воткнуть человека, прошедшего мясорубку?

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

По дороге почешут ЧСВ все виды HR, тимлидов, старших разработчиков и прочих, кто в составе пяти человек должен «разговаривать разговоры». Уважаемые читатели моего канала, вы должны чётко понимать, какой сдвиг парадигмы происходит на этом примере. Целью тупой автоматизации становятся такие же тупые рабочие процедуры. Все пересекающиеся, кто сформировался как доброкачественный нарост вокруг создания и эксплуатации программ, будут отваливаться и перестраиваться. Просто потому, что большинство программ будет автоматизироваться таким чудесным образом. Это также наглядно демонстрирует отсутствие полезного действия в таких процессах. Ведь создатели этого продукта не выдумали все шаги и процедуры из головы — от постановки задачи на интервью до содержания и получения саммари. Нет, они просто «поддержали» существующие распространённые процессы.

Когда в очередной виток оптимизации с очередными заблудившимися командами разработки я шучу про созвоны и их ненужность — я на самом деле не шучу. Тем, кто говорит, что созвоны повышают качество и результативность, я предлагаю увеличить их до полного рабочего дня. Тогда результативность должна вырасти. В ответ обычно сообщают: «Ты что, надо же программировать, мы же важное обсуждаем, делать будем то, что обсудили». Окей, и тут выясняется, что есть какое-то саммари, которое надо делать, а появилось оно из какой-то повестки, которой на самом деле никогда не было. Потому что все встречи проходят в режиме «чокакиев» — «чё, как у нас дела». Когда я прошу показать все повестки и саммари, чтобы прочертить смысловое движение, оказывается, что их никогда не было. Все просто созванивались. А что мне надо — можно искать в трекере. Это такое кладбище попыток саморефлексии каждого, кто до него дотянулся. Но даже там найденные связи, выстроенные в цепочки, показывают, что траектории не было, а движение хаотичное и противоречивое. Поэтому работали-работали, делали-делали, а результатов как-то нет. Потому что непонятно, что вообще является общим результатом. А зачем тогда были созвоны?

Теперь есть прекрасный инструмент, и весь карьеростроительный движ накрывается медным тазом. В прекрасное время живём!

Полностью согласен c Егором:

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

Проблемы Prompt-программирования