В файлах по делу Эпштейна есть вот такенный файл: https://www.justice.gov/epstein/files/DataSet%209/EFTA00315849.pdf

Внутри 158 страниц забористых примеров всякого растления малолетних линуксоидов на BASH образца 2005-го года.

Там же указаны имена авторов сего документа, очевидно связанных с консультированием покойного Эпа Штейна:

* Chet Ramey, Case Western Reserve University
* Brian Fox, Free Software Foundation

Я давно знал о тлетворном влиянии обожаемого мною программирования на bash, но даже и не подозревал о масштабах трагедии! Спасибо товарищам Рамею и Фоксу за долголетнюю службу на благо обществу свободного ПО!

https://testitquickly.com/2026/02/20/mesterul-manole-rastoarna-caldarea/

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

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

Есть книга Роберт Пëрсиг «Дзэн и искусство ухода за мотоциклом»

Рычу от удовольствия! Вроде ни про что конкретно, но о чëм-то очень базовом и важном; постоянно отвлекаюсь на «это надо обдумать».

Краткий пересказ: один чувак в США изучал философию, свихнулся, вышел из дурдома, обзавелся друзьями, взял своего сына, одежду, большое острое мачете и все вместе на двух мотоциклах (Honda & BMW) поехали в семнадцатидневное мотоциклопутешествие из Миннеаполиса в Сан-Франциско. Смартфона у автора нет, поэтому по пути он постоянно думает об основах мироздания и прописывает базу подхода к работе в будущих айтишных офисах XXI-го века. В итоге до куда они там ехали доезжают только двое. Кагбэ всë.

Книга 1974-го, но изложенная в ней база до сих пор верна — перед тобой встаёт НЁХ (тикет), которую надо решить, чтобы она передвинулась в Done. А как ты решишь то, что непонятно откуда взялось и хз как оно работает? А точно так же, как дворовые пацаны чинят моцотиклы и потом злят мусоров — вовлекаешься в задачу (присутствуешь), расчехляешь научный метод познания, выдвигаешь гипотезы и проверяешь их одну за другой, пока проблема не будет решена. Одной рукой читаешь справочник моториста, второй листаешь Канта чтобы понять, откуда мы вообще знаем то, что мы знаем (источник требований для тест-кейса), и как мы определяем, верно ли оно или придумалась очередная чертивня. И так в цикле.

В какой-то момент понимаешь, что весь тест-дизайн основан на принципах ремонта первого массового «супербайка» Honda CB750 1969-го.

Автор работал учителем и техписом для компьютерщиков IBM, так что его рассуждения нам ясны и понятны.

В одном из ранних интервью Пирсиг отмечал, что разные издательства отклоняли книгу 121 раз, прежде чем издательство Уильяма Морроу приняло её к изданию (что является рекордом Книги рекордов Гиннесса). На деле издательства отклоняли не всю книгу, а только краткую заявку на неë, но всем как всегда…

https://testitquickly.com/micropost/%d1%8d%d1%82%d0%be-%d0%bd%d0%b0%d0%b4%d0%be-%d0%be%d0%b1%d0%b4%d1%83%d0%bc%d0%b0%d1%82%d1%8c/

Наткнулся на канал, который настойчиво прогнозирует технологическое будущее человечества

Если суметь посмотреть (в бездну) без истерики, то LLM в отдельных задачах рулез, но в целом — нездоровая тема.

Хорошо, когда LLM помогает что-то сделать или понять. Но…

Это ПО: не всегда адекватно, не всегда стабильно, иногда меняется, иногда недоступно (saas же)… И не может ПО «учиться на исправлении ошибок». Истинная галлюцинация LLM в том, что это все воспринимается хьюманами как результат чего-то интеллектуального.

LLM подстегивают возможность снижать и техническую, и когнитивную рабочую нагрузку, а это незаметно размывает/ослабляет рабочие навыки. Как же это похоже на судьбу многих менеджеров! Постоянно кажется, что ты всë понимаешь и можешь в любой момент вмешаться и сделать как надо, а когда таки надо вмешаться — ты ВНЕЗАПНО не понимаешь, что там происходит, не можешь что-то исправить, не управляешь ситуацией, но все еще обязан за все это отвечать.

Ты уже вообразил себя «AI-кентавром», в котором ты постоянно сидишь в разделе управляющей головы, а на деле тебе уже поручили шуршать копытами, которые незаметно переходят в раздел лошадиной задницы, по которой постоянно и заметно больно стегают плеткой, чтобы ты громче игогокал и шибче скакал не спрашивая, куды мы бегим и зачем. Ну что ты за голова, если уже не понимаешь, как там все устроено и уже неспособен объявить новую функцию с одной переменной без запроса в LLM?!

А еще могут исчезнуть компании, которые держат LLM на своих серверах. А у тебя pipeline уже полностью на удаленном Claude. А оно обанкротилось.

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

Поэтому да, the planet is fine…

https://youtube.com/clip/Ugkxq-M0KSdm1QH1huzUgzBkhzNnhcZpTdYy?si=OWu67alyrJvWuKqJ

В конце игры останутся только две компании, которые будут хоть кого-то хоть как-то нанимать:
* openai
* anthropic

Andrej Karpathy:
Personal update: I've joined Anthropic.
https://x.com/karpathy/status/2056753169888334312

https://quality-lab.ru/blog/kakie-zadachi-v-testirovanii-pora-otdat-ii-chtoby-poluchit-rezultat-a-ne-novye-problemy/

Вязанный бабушкой енот в деле

Доброго ранку,
Запрошую тебе сьогодні о 20:00 у Сувору QA ком'юніті на панельну дискусію «Ми всі тепер АІ-експерти. Чи ні?»

AI вже всюди: у роботі, в побуті, в резюме, у вакансіях, у чатах, у задачах і, здається, навіть у місцях, де його ніхто не очікував.

Тому ми вирішили зібрати панельну дискусію і поговорити про те, що зараз відбувається з AI в IT та навколо нього.

Разом із запрошеними експертами обговоримо:
- які AI-тренди зараз справді варті уваги;
- що робити, коли AI вже всюди;
- як ефективно використовувати AI у роботі;
- де AI реально допомагає, а де заважає;
- як змінюється роль спеціалістів у командах;
- і чи всі ми тепер справді АІ-експерти, чи просто дуже стараємось такими виглядати 😄

Ведучий панельної дискусії: Костянтин Телтов, QA Team Lead / SDET

Запрошені експерти:
▶️ Євген Пасєка, QA Manager у SQUAD
▶️ Марина Дідковська, Senior Director, Quality Architecture at EPAM Systems
▶️ Олексій Іващенко, QA Team Lead в TheyDo
▶️ Анна Величко, Senior Software Engineer in Test

Усі наші експерти не просто говорять про AI, а вже активно впроваджують його у своїх компаніях та командах.

Приєднуйся, щоб дізнатись, як це працює на практиці, з чого почати і як використати цей досвід саме у своїй роботі.

📅 Коли: 25 червня, 20:00
🎟 Квитки тут (50% вартості квитка йде на ЗСУ)
🔴 Запис буде

1. Впихнуть своё резюме в chatGPT с запросом:

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

2. Читать ответ.

Понимать, что, собственно, именно так твоё замечательное резюме воспринимают наши славные Неизвестные отцы-рекрутеры — злобно и безжалостно трезво. А современные системы отпинывания кандидатов от компании (ATS) как раз и делают краткие саммари по всем резюме, которые ещё не были автоматически перемещены в газенваген. Ну и вот.

Например, в отношении меня бездуховной железякой были предъявлены орфографические ошибки:

«Для человека, который позиционирует себя как тренер по QA и свободно владеет английским:

consalter
appications
Roumanian
re￾quirements (артефакт PDF)
M ay

Часть — ошибки OCR, но часть присутствует именно в тексте».

Да, ошибки не должно наличествовать в таком святом документе, исправил. Однако наглые формулировки…

А дальше ВНЕЗАПНО очень плохое:

Рекомендация от последнего работодателя вызывает вопросы

Подписана CTO. Однако письмо выглядит необычно:

нет фирменного бланка;
нет логотипа;
нет адреса компании;
только текст и email.

Рекомендация выглядит слабее, чем должность. Для Team Lead обычно пишут про:

руководство людьми;
принятие решений;
влияние на процессы;
достижения команды.

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

Ну ёптыть, какой pdf дали, такой и использую… Но кто будет разбираться?

Ок, рекомендуется эту рекомендацию удалить. Удалил.

Дальше вообще ой:

Вторая рекомендация подтверждает работу в Astound Commerce до 2020 года.

Она не подтверждает:

работу в криптоплатформе;
работу Team Lead;
нынешний консалтинг.

Так стоп! (© КВН) В Astound Commerce всего этого и не было, это всё было ПОСЛЕ. Но кто будет разбираться?

По этому резюме нельзя сделать вывод о мошенничестве. Однако противоречие между заявленной должностью QA Team Lead и содержанием рекомендательного письма является наиболее сильным признаком, требующим проверки.

Наиболее объективно проверяются:

* действительно ли человек работал Team Lead;
* действительно ли письмо подписал указанный CTO;
* существовала ли указанная должность именно в этот период;
* подтверждается ли опыт в LinkedIn, GitHub, конференциях, публикациях и других независимых источниках.

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

А если бы моё резюме было безусловно-прекрасным, отвечающим на все вопросы до того, как их задали, то и его кинут фтопку, потому что слишком всё прекрасно, ненатурально, а значит, это мошеннический фрод, Фродо!

https://youtu.be/WdbqPK2Bof4?si=GH5e1YkRQCXBJI-K&t=50

Вкратце цитата из https://t.me/RakovskyXP/153:

Есть такая широко известная в узких кругах [широких] тестировщиков Элизабет Хендриксон.

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

- Зачем ты выдумываешь новый функционал?!

- Что значит, новый функционал? Это же недоработка, баг.

- Нет, Элизабет, - говорили ей, - баг - это когда что-то работает не так, как планировалось. А вот так, как ты хочешь, оно никогда и не планировалось. Ты просто называешь новый функционал багами.

И попробуй объяснить, что тестировщик занимается неосознанным вредительством, раздувая без того передутый скоуп работ на ровном месте.

Всегда так было и всегда так будет.

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

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

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

А на стороне заказчика программисты сидят (например, в Шри-Ланке) и злобно отпинывают всё, что «не по требованиям», потому что им за баги не просто втыкивают втык, а их ещё и наказывают штрафами.

А архитекторы смыслов на стороне заказчика сидят в (тогда ещё не знавших налета самолетов) башнях международного торгового центра в NY, бесконечно фигачат новые требования и сильно нервничают, когда им приходится по семь раз в день читать разные баг-репорты всё об одном и том же, и особенно сильно говорят вслух, что «ДА ТВОЙ КРОЛИК ПИШЕТ!», когда к ним прилетают баги, найденные по непредусмотренному сценарию.

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

Элизабет попала в промежуточное состояние — когда команда небольшая, всяческие предложения об улучшении приветствуются, но разработка всё сильнее переходит на рельсы «Мы договорились сделать так, и сделали именно так», потому что у них стала важнее стабильность и воспроизводимость работы всего проекта, нежели глобальное «А давайте добавим Bluetooth, станет удобнее!» или вроде бы адекватное «Данные приходят корректно, но есть лишнее поле; хорошо было бы его не передавать…» А давайте не надо нам делать отдельную петлю проверки наличия отсутствия отдельного поля…

Хочется однозначности, но…

Про почкование

Слышал как-то одну прикольную историю от Дейва Томаса. Одна команда в огромной американской конторе топила за XP. Им от нечего делать сунули проект, который полтора года никак не мог сдвинуться с мёртвой точки. Они сдали его за месяц. Начальник мрачно офигел и пошёл выяснять, как это они так. Они говорят: ну, тесты, рефакторинг, парное программирование, все такое. Начальник: отлично, научите этому всю компанию. А они ему: нет, Дед Мороз, погоди.

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

Всю компанию так не перевернули, но здоровенный кусок организации переехал на XP.

Моя история

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

Мне нужна была пустая команда. Новый проект, ноль человек, найм на мне. И когда я её нашёл, набирать пришлось быстро, а учить — ещё быстрее. И я вспомнил тот доклад.

Первого человека я учил сам. Сел с ним в пару, и мы вместе писали тесты. Через три недели пришли ещё двое: одного взял я, второго — мой первый напарник. Дальше по той же схеме. За три месяца — шесть человек, и результат отличный: эти ребята работают со мной до сих пор.

Осталась с нами и схема. Любой новичок первые несколько недель сидит в паре с носителем и пишет боевой код.

К чему это всё

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

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